La faille BD-J du lecteur PS3 bloquée par Sony

[baboulette]

pas tant que ca finalement , je suis meme sur qu'on peut faire tourner des truc e 3d assez exigeant sans probleme dessus , apres c'est qu'une question de codage^^

Oui tu peux réinventer la roue ,c'est à dire faire tout ce que la CG peut faire en hard, te le taper en soft..

Ca demande un boulot monstre, et une connaissance du proc sur le bout des doights.

On à l'impression de revenir au debut des années 80, ou le proc devait se taper toute la gestion graphique.

Donc je comprends qu'aucun dév amateur n'a envi de se casser le cul pour ca, sachant qu'ils y auront accès tôt ou tard au RSX.

personne ne dit le contraire, mais ca limite pas mal quand meme.

C'est breveté ça !!!

Modifié 24 octobre 2008 par baboulette

[ouasse]

je comprends qu'aucun dév amateur n'a envi de se casser le cul pour ca, sachant qu'ils y auront accès tôt ou tard au RSX.

tu est bien mal renseigné. Il y a une catégorie de fanas de programmation qui adore faire ce genre de trucs (la scène démo). Je sais qu'il y a des librairies 3D en cours de préparation (dont la mienne). C'est juste que le développement initial est plus long que si on a tout directement tout cuit sous le nez, mais ensuite, il y aura des prods ps3, je te le garantis.

[baboulette]

tu est bien mal renseigné. Il y a une catégorie de fanas de programmation qui adore faire ce genre de trucs (la scène démo). Je sais qu'il y a des librairies 3D en cours de préparation (dont la mienne). C'est juste que le développement initial est plus long que si on a tout directement tout cuit sous le nez, mais ensuite, il y aura des prods ps3, je te le garantis.

Peut etre, mais 3 pelés 2 tondus, ne peuvent pas tout faire !!!

Et si tu développes avec eux, tu es le premier à savoir le boulot que ca represente.

Je ne dis pas que rien n'est possible, mais qu'il faut bcp de monde pour crée des api ..

Modifié 24 octobre 2008 par baboulette

[wirl]

tu est bien mal renseigné. Il y a une catégorie de fanas de programmation qui adore faire ce genre de trucs (la scène démo). Je sais qu'il y a des librairies 3D en cours de préparation (dont la mienne). C'est juste que le développement initial est plus long que si on a tout directement tout cuit sous le nez, mais ensuite, il y aura des prods ps3, je te le garantis.

Peut etre, mais 3 pelés 2 tondus, ne peuvent pas tout faire !!!

Et si tu développes avec eux, tu es le premier à savoir le boulot que ca represente.

Je ne dis pas que rien n'est possible, mais qu'il faut bcp de monde pour crée des api ..

Pourquoi ?

Il est clair qu'il y a 1000 fois plus de gens qui attendent qu'il se passe quelque chose que de gens qui agissent (Bon c'est sur, c'est pas donné à tout le monde).

Toute fois il est bien utile que quelqu'un commence, si tout le monde part sur ton principe il ne se passerait jamais rien.

Il est impératif que certains ouvrent la voie.... 1000 mercis à eux

Modifié 24 octobre 2008 par wirl

[baboulette]

Pourquoi ?

Il est clair qu'il y a 1000 fois plus de gens qui attendent qu'il se passe quelque chose que de gens qui agissent (Bon c'est sur, c'est pas donné à tout le monde).

Toute fois il est bien utile que quelqu'un commence, si tout le monde part sur ton principe il ne se passerait jamais rien.

Il est impératif que certains ouvrent la voie.... 1000 mercis à eux

Tout simplement que ca menera à rien !!

Un proc, ne remplacera jamais une CG, et faire en soft ce quelles font en hard ca consomme bcp trop de CPU pour le reste de l'applis ..

On peut implementer quelques fonctions, mais c'est tout.

Y'a qu'a voir ce que ca donne sur un pc, avec des jeux ou demos en 3D logicielle, pour les sceptiques vous avez qu'a tester.

[ouasse]

Un proc, ne remplacera jamais une CG, et faire en soft ce quelles font en hard ca consomme bcp trop de CPU pour le reste de l'applis ..

On peut implementer quelques fonctions, mais c'est tout.

Y'a qu'a voir ce que ca donne sur un pc, avec des jeux ou demos en 3D logicielle, pour les sceptiques vous avez qu'a tester.

bah en meme temps 99% des personnes interrogées veulent l'accès au RSX sur PS3 pour pouvoir faire tourner des softs de PC dessus, c'est à dire des softs qui n'utiliseront que le PPE du Cell, c'est à dire qui utiliseront meme pas 10% de la puissance du proc de la PS3.

Il faut arrêter de voir le Cell comme un processeur de PC. Le Cell est prévu pour ce genre d'applications, alors qu'un proc de PC est beaucoup plus générique et donc moins efficace pour ce genre de tâches spécifiques, d'où la nécessité d'une carte 3D.

[baboulette]

Un proc, ne remplacera jamais une CG, et faire en soft ce quelles font en hard ca consomme bcp trop de CPU pour le reste de l'applis ..

On peut implementer quelques fonctions, mais c'est tout.

Y'a qu'a voir ce que ca donne sur un pc, avec des jeux ou demos en 3D logicielle, pour les sceptiques vous avez qu'a tester.

bah en meme temps 99% des personnes interrogées veulent l'accès au RSX sur PS3 pour pouvoir faire tourner des softs de PC dessus, c'est à dire des softs qui n'utiliseront que le PPE du Cell, c'est à dire qui utiliseront meme pas 10% de la puissance du proc de la PS3.

Il faut arrêter de voir le Cell comme un processeur de PC. Le Cell est prévu pour ce genre d'applications, alors qu'un proc de PC est beaucoup plus générique et donc moins efficace pour ce genre de tâches spécifiques, d'où la nécessité d'une carte 3D.

Je ne dénigre pas le travail que vous faites, c'est tout à l'honneur des gens qui bossent pour faire avancer les choses.

Le CELL n'est pas un proc de PC, tu viens de toucher un point sensible justement.

Car son architecture non conventionelle, en fait justement un defaut, pour en tirer la puissance, il faut penser CELL, développer CELL et oublier un peu tout ce que l'on sait.

Meme si le cell est trés puissant (ce que je ne doute pas), ecrire des fonctions softs pour remplacer celles en hard est trés dur sur des x86 assez facile à programmer, alors je te raconte pas sur le cell.

De plus le cell n'aura pas que la 3D à gerer.

Vous arriverais surement à faire de superbes choses avec, mais sans le RSX, vous irez pas bien loin dans les applis graphiques.

A voir les difficultés qu'ont des devs professionnels à tirer parti du cell, avec toute l'assistance de sony, et les kits qui vont bien.

Modifié 27 octobre 2008 par baboulette

[sephirothff]

c'est pas plus dur de coder sur cell que sur x86 , c'est juste que le systeme differe , il suffit juste au devellopeur de trouver ces marques sur le systeme et c'est parti

Modifié 28 octobre 2008 par sephirothff

[peperocket]

Certains postes sont de plus en plus durs à lire, sérieux, faites un effort sur votre écriture, au moins relisez vous une fois....parce que là c'est niveau maternel...

[ouasse]

Le CELL n'est pas un proc de PC, tu viens de toucher un point sensible justement.

Car son architecture non conventionelle, en fait justement un defaut, pour en tirer la puissance, il faut penser CELL, développer CELL et oublier un peu tout ce que l'on sait.

Penser Cell, Développer Cell, oui, sans aucun doute, parce qu'effectivement il faut penser qu'on doit programmer pour 6 processeurs vectoriels à mémoire locale, ce n'est pas forcément pareil qu'un processeur de PC plus ou moins vectoriel (ça dépend si on compte tirer le max de puissance du cpu) avec plusieurs coeurs à mémoire partagée.

Quant à oublier tout ce qu'on sait, faut pas exagérer, il y a un temps d'adaptation certes, mais un programme C reste un programme C, il faut juste penser à utiliser au maximum le coté vectoriel et utiliser la RAM de la machine comme une sorte de périphérique de stockage ultra rapide.

Meme si le cell est trés puissant (ce que je ne doute pas), ecrire des fonctions softs pour remplacer celles en hard est trés dur sur des x86 assez facile à programmer, alors je te raconte pas sur le cell.

Ba déjà sur les cartes graphiques dernière génération, tous les algos qui avaient été câblés en hard sont maintenant du soft tournant sur les GPU. Cela permet de reprogrammer ses propres shaders et même d'utiliser les cartes graphiques comme processeur de calcul pour faire autre chose que du graphisme.

De plus le cell n'aura pas que la 3D à gerer.

Vous arriverais surement à faire de superbes choses avec, mais sans le RSX, vous irez pas bien loin dans les applis graphiques.

Ca c'est vrai, sans RSX on n'aura pas les mêmes résultats, ça c'est sur. Mais n'oublie pas qu'on reste dans le domaine du homebrew. Regarde les autres plate-formes où les accélérations 3D ne sont pas forcément bloquées. Est-ce que de toutes façons les homebrews atteignent les performances des jeux vidéo ? Forcément non, parce que faire même une démo à 2 ou 3 ce n'est pas pareil qu'un jeu développé par plusieurs dizaines de personnes.

Sur PSP que je connais un peu mieux que les autres plate-formes, les quelques rares homebrews qui exploitent bien l'accélération 3D sont le jeu No Gravity et quelques démos issues de la demoscene. Et le niveau est bien en dessous des meilleurs jeux PSP. Et alors ? le but est de s'amuser à programmer, si possible en faisant profiter les autres de ce qu'on a fait.

Alors après, encore une fois oui, sans RSX on peut considérer que l'on a affaire à une machine différente de la vraie PS3, mais qu'importe ? Si déjà on arrivait à tirer parti des performances auxquelles on a accès, on pourrait faire bien plus que ce qui est fait actuellement simplement en recompilant des applis PC qui ne tournent que sur le PPE.

On pourra regretter le RSX au vu des perfs pures données par le Cell lorsqu'il sera exploité à fond. Mais déjà je suis bien curieux de savoir ce que pourra donner le Cell tout seul. Je t'avoue à la fois n'en avoir aucune idée (mes expérimentations ne sont pas assez avancées pour savoir) et avoir bon espoir (pour l'instant je n'ai pas réussi à pousser un SPE à fond, donc je ne vois pas encore la limite ce qu'il est capable de faire)

A voir les difficultés qu'ont des devs professionnels à tirer parti du cell, avec toute l'assistance de sony, et les kits qui vont bien.

Heu là franchement, si les boites de développement embauchaient des bons programmeurs, elles n'auraient pas ce genre de problèmes. Personne de m'a aidé pour me mettre à programmer sur Cell. Google, les docs et le forum IBM sont suffisants pour s'y mettre.

[baboulette]

Ba déjà sur les cartes graphiques dernière génération, tous les algos qui avaient été câblés en hard sont maintenant du soft tournant sur les GPU. Cela permet de reprogrammer ses propres shaders et même d'utiliser les cartes graphiques comme processeur de calcul pour faire autre chose que du graphisme.

Non, les fonctions hards restent en hard,seulement les GPU sont devenus de plus en plus programmables pour une plus grande flexibilité, par exemple avec cuda,nvidia à permi la gestion hard des algos soft du physx, sans avoir le PPU d'ageia.

Ce que je veux dire par tout oublié, c'est pas bien sur qu'il faut changer de langage de programmation, mais juste la facon de programmer, un x86 ne se programme pas du tout comme un CELL.

Deja la gestion mémoire n'a rien à voir, les registres etc ..

Le CELL doit surement travailler exclusivement en 64 bits, avec ses SPE qui n'ont rien à voir avec des cores.

Dans l'obsolu oui un proc reste un proc, mais pour faire tout faire par le cell, il faudra bien plus que des addition ,soustraction via les registres.

Les applis multitreadées, surtout pour le cell, sont très dures à gérer et à mettre en place, surtout en partant de quasiment rien.

Modifié 28 octobre 2008 par baboulette

[ouasse]

Ce que je veux dire par tout oublié, c'est pas bien sur qu'il faut changer de langage de programmation, mais juste la facon de programmer, un x86 ne se programme pas du tout comme un CELL.

Deja la gestion mémoire n'a rien à voir, les registres etc ..

C'est différent, mais cela n'a pas rien à voir. Une boucle reste une boucle, un entier reste un entier, un flottant un flottant.. Une fonction quelconque écrite en C peut être compilée directement sur SPE. Seule la fonction main a besoin de changer pour ce qui est de la récupération des données et sortie des résultats.

Effectivement la gestion mémoire change, c'est la différence majeure. Cela dit les algos que l'on va programmer vont utiliser la mémoire locale, et le programme principal va faire les transferts vers la RAM entre les itérations, un peu comme si on chargeait depuis un disque, sauf que la RAM est bien sur plus rapide.

Le CELL doit surement travailler exclusivement en 64 bits, avec ses PPE qui n'ont rien à voir avec des cores.

Pas du tout. Déjà le PPE est le coeur principal et il est compatible avec l'architecture POWER5, et fonctionne au choix en mode 32 bits ou 64 bits, et dans chaque mode, on peut manipuler des entiers de 32 ou 64 bits (registres de 64 bits).

Ensuite les coeurs spécialisés (SPE) peuvent se programmer avec des entiers ou flottants de 32 ou 64 bits, sans aucun souci. Evidemment on ne tirera le maximum de performance que si l'on utilise les fonctionnalités vectorielles, mais je dirais que ce n'est pas différent des x86 qui disposent d'instructions vectorielles équivalentes (extensions SSE, SSE2, ...). Un programme x86 qui utilise efficacement les extensions vectorielles ira plus vite qu'un programe purement scalaire (= pas vectoriel). C'est pareil sur les SPE.

Dans l'obsolu oui un proc reste un proc, mais pour faire tout faire par le cell, il faudra bien plus que des addition ,soustraction via les registres.

Pourtant sur x86 ou Cell le problème est le même, il faut utiliser l'architecture au maximum pour en tirer un maximum de performance. En cela le Cell n'est pas si différent avec ses coeurs multiples et ses instructions vectorielles.

Les applis multitreadées, surtout pour le cell, sont très dures à gérer et à mettre en place, surtout en partant de quasiment rien.

Le multithreading sur Cell se programme exactement pareil que sur x86. On utilise généralement les threads posix, ce qui permet la synchro entre les threads PPE et les threads SPE, la gestion de partage de variables en RAM, etc.

Juste une remarque : avec toutes les idées reçues que tu nous sers, je peux comprendre que tu n'aies jamais essayé de programmer le moindre programme sur Cell, ne serait-ce un hello world ou un petit proof of concept de base. Mais franchement, essaie, documente-toi, rentre un peu dedans et fais-toi ta propre opinion.

[erwan2004]

Le Cell peut travaillé en 32 ou 64bits mais ce dernier est a évité .

Le problème du Cell reste aussi la répartition des taches ou du processus sur tous ces SPE , on voie bien au sur X86 c'est déjà pas terrible alors sur Cell ....

Parce qu'au contraire d'une carte graphique qui parallélise tous le boulot sur ces unités de traitement , le Cell lui c'est à la main qu'il faut le faire .

Heu là franchement, si les boites de développement embauchaient des bons programmeurs, elles n'auraient pas ce genre de problèmes. Personne de m'a aidé pour me mettre à programmer sur Cell. Google, les docs et le forum IBM sont suffisants pour s'y mettre.

Temps, argent, business ...

[baboulette]

Juste une remarque : avec toutes les idées reçues que tu nous sers, je peux comprendre que tu n'aies jamais essayé de programmer le moindre programme sur Cell, ne serait-ce un hello world ou un petit proof of concept de base. Mais franchement, essaie, documente-toi, rentre un peu dedans et fais-toi ta propre opinion.

J'avoues que ca me tente pas, du moins pour l'instant ..

En ce moment je programme plutot des jeux sur les vieilles consoles (Pc engine) pour une assos, et qd on voit le casse tete que c'est sur ces machines (qui sont rien par rapport a celles d'aujourd'hui) vu le manque de doc, j'imagine à peine la ps3.

Je viens de voir les demos que tu as posté, le cube est pas mal,mais je voyais la meme chose sur amiga en 1990.

le but est de s'amuser à programmer, si possible en faisant profiter les autres de ce qu'on a fait

La je dis , 100% d'accord !!

Mais bon si tu trouves que tout faire à la mano, et par le CELL c'est presque une partie de plaisir, je suis pas contrariant

En tout cas bon courage .

Modifié 28 octobre 2008 par baboulette