Humm... "Allo Intel, arrêtez vos bricolages avec vos Core i7 à 3 GHz, soyez un peu pro et flashez des softcores dans des FPGAs..."
Ce n'est pas parce que Yasep est réalisé en mode "pour le fun" qu'il faut se ridiculiser en tirant à boulets rouges sur ceux qui font (beaucoup) mieux que soi*t*.
Pour l'instant, c'est vous qui vous ridiculisez en tirant des conclusions sur des bases erronées (quelle qu'en soit la raison).
D'abord, je ne tire à boulets rouges sur personne ou rien : j'arrête depuis longtemps de me plaindre, ce qui explique le long hiatus de F-CPU, afin de mettre au point mes propres systèmes libres. Je les fais pour moi, mon boulot et parce que je le peux, et si ça intéresse ou aide d'autres, tant mieux, qu'ils se servent, c'est fait pour.
D'autres font mieux que moi, chacun son domaine, et quand je bosse, je prends ce qu'il faut pour le client, en laissant la philosophie derrière, car on me paie pour que ça marche(tm). Si un projet implique une techno que je ne maitrise pas ou qui ne m'intéresse pas, je peux confier le dossier à un collègue plus compétent. Je n'ai donc pas de comptes à régler avec Intel ou autre. Bon, je suis pas content de la fondation Raspberry Pi (ça se fait pas de foutre les clients dans la merde) et les prochaines cartes WizYasep remplaceront les Pi que j'ai déjà installés, donc râler est une perte de temps et d'énergie.
Ensuite, si vous relisez cette page, vous verrez que le YASEP est un tout petit 16-32 bits. Le comparer à un i7 à 3GHz est absurde, et vous me prêtez encore des intentions que j'ai déjà longuement contredites dans ce thread (qui commence à devenir long aussi). Et Intel fait ce qu'il veut, c'est le DOJ ou les actionnaires que ça regarde.
Aussi, Sytoka Modon a bien compris, lui, que lorsque je parle de "bricolage", c'est bien de l'architecture x86 et ses évolutions depuis le 8080 donc je parlais. Je ne vais pas répéter ce qui fait la réputation de cette architecture horrible, et même s'il y a eu des améliorations avec x86_64, ça reste... une horreur. J'ai arrêté de lire les interminables manuels avec l'arrivée du PII.
Enfin, vous citez "c'est d'abord un "vrai" 64 bits," et vous parlez du YASEP alors que le début de la phrase spécifie bien "Pour ce qui est de F-CPU". Ce n'est pas un bon moyen pour faire avancer le Schmilblick (euphémisme inside).
J'envisageais plutôt de considérer la "grille" de led comme un écran standard.
Ce qui revient à quoi, en pratique, matériellement ? Si la sortie vidéo standard est utilisée, donc il faut décoder le HDMI avant de l'envoyer par RJ45 vers les cartes wizyasep (qui sont conçues pour être plus puissantes que les cartes PixelPusher du commerce). C'est un appareil cher à concevoir en plus.
Ensuite si vous tenez vraiment à passer par l'écran du point de vue du logiciel alors allez lire dans la mémoire du framebuffer pour construire les paquets UDP.
Quel problème tenez-vous donc à résoudre ?
générer les animations, lire de la vidéo
Les vidéos sont généralement pré-encodées dans un format adapté. Mais cela importe peu puisque chaque carte, qui contrôle une zone d'écran, reçoit les données en temps réel par Ethernet. Tant que l'ordre des pixels est bon, dans un paquet valide, la source importe peu pour cette carte. Ce peut être de la 3D temps réel, du H264, une caméra, un VJ,... Pour la carte c'est juste des octets à transformer en purée de bits.
plutôt que de tout coder en dur dans un automate à état sur un processeur atypique.
Pardon ? Me suis-je exprimé si mal ? Ai-je mal compris ? Comment coderais-je "en dur dans un automate à état sur un processeur atypique" des vidéos comme celle-ci (un zoom très profond dans Mandelbrot qui dure 30s) https://www.facebook.com/101308076630787/videos/848924055202515/
Des fois que ce ne soit pas encore assez clair : la carte wizyasep reçoit un flux UDP par réseau 100Base-T pour envoyer les valeurs de pixels sur une vingtaine de sorties séries asynchrones avec des timings très précis. La surface totale de l'écran est divisée en sections, avec chacune leur propre carte WizYasep. La source des données peut être n'importe quel type de machine qui streame les données sur le réseau. Un PC sous l'OS de votre choix ou une minicarte embarquable sous Linux (mon choix car plus fiable).
[^] # Re: Court circuit
Posté par Yann Guidon (site web personnel) . En réponse à la dépêche Le retour de F-CPU, le processeur libre. Évalué à 3.
Bonjour,
Pour l'instant, c'est vous qui vous ridiculisez en tirant des conclusions sur des bases erronées (quelle qu'en soit la raison).
D'abord, je ne tire à boulets rouges sur personne ou rien : j'arrête depuis longtemps de me plaindre, ce qui explique le long hiatus de F-CPU, afin de mettre au point mes propres systèmes libres. Je les fais pour moi, mon boulot et parce que je le peux, et si ça intéresse ou aide d'autres, tant mieux, qu'ils se servent, c'est fait pour.
D'autres font mieux que moi, chacun son domaine, et quand je bosse, je prends ce qu'il faut pour le client, en laissant la philosophie derrière, car on me paie pour que ça marche(tm). Si un projet implique une techno que je ne maitrise pas ou qui ne m'intéresse pas, je peux confier le dossier à un collègue plus compétent. Je n'ai donc pas de comptes à régler avec Intel ou autre. Bon, je suis pas content de la fondation Raspberry Pi (ça se fait pas de foutre les clients dans la merde) et les prochaines cartes WizYasep remplaceront les Pi que j'ai déjà installés, donc râler est une perte de temps et d'énergie.
Ensuite, si vous relisez cette page, vous verrez que le YASEP est un tout petit 16-32 bits. Le comparer à un i7 à 3GHz est absurde, et vous me prêtez encore des intentions que j'ai déjà longuement contredites dans ce thread (qui commence à devenir long aussi). Et Intel fait ce qu'il veut, c'est le DOJ ou les actionnaires que ça regarde.
Aussi, Sytoka Modon a bien compris, lui, que lorsque je parle de "bricolage", c'est bien de l'architecture x86 et ses évolutions depuis le 8080 donc je parlais. Je ne vais pas répéter ce qui fait la réputation de cette architecture horrible, et même s'il y a eu des améliorations avec x86_64, ça reste... une horreur. J'ai arrêté de lire les interminables manuels avec l'arrivée du PII.
Enfin, vous citez "c'est d'abord un "vrai" 64 bits," et vous parlez du YASEP alors que le début de la phrase spécifie bien "Pour ce qui est de F-CPU". Ce n'est pas un bon moyen pour faire avancer le Schmilblick (euphémisme inside).
Ce qui revient à quoi, en pratique, matériellement ? Si la sortie vidéo standard est utilisée, donc il faut décoder le HDMI avant de l'envoyer par RJ45 vers les cartes wizyasep (qui sont conçues pour être plus puissantes que les cartes PixelPusher du commerce). C'est un appareil cher à concevoir en plus.
Ensuite si vous tenez vraiment à passer par l'écran du point de vue du logiciel alors allez lire dans la mémoire du framebuffer pour construire les paquets UDP.
Quel problème tenez-vous donc à résoudre ?
Les vidéos sont généralement pré-encodées dans un format adapté. Mais cela importe peu puisque chaque carte, qui contrôle une zone d'écran, reçoit les données en temps réel par Ethernet. Tant que l'ordre des pixels est bon, dans un paquet valide, la source importe peu pour cette carte. Ce peut être de la 3D temps réel, du H264, une caméra, un VJ,... Pour la carte c'est juste des octets à transformer en purée de bits.
Pardon ? Me suis-je exprimé si mal ? Ai-je mal compris ? Comment coderais-je "en dur dans un automate à état sur un processeur atypique" des vidéos comme celle-ci (un zoom très profond dans Mandelbrot qui dure 30s)
https://www.facebook.com/101308076630787/videos/848924055202515/
Des fois que ce ne soit pas encore assez clair : la carte wizyasep reçoit un flux UDP par réseau 100Base-T pour envoyer les valeurs de pixels sur une vingtaine de sorties séries asynchrones avec des timings très précis. La surface totale de l'écran est divisée en sections, avec chacune leur propre carte WizYasep. La source des données peut être n'importe quel type de machine qui streame les données sur le réseau. Un PC sous l'OS de votre choix ou une minicarte embarquable sous Linux (mon choix car plus fiable).
On va peut-être y arriver un jour.