"ouvrir" le code d'un DSP n'est pas dans les moeurs des constructeurs, c'est ce que je dit.
Juste pour préciser, quand je dis "ouvrir", c'est avoir la doc des opcodes, c'est tout. C'est la base, quand même ...
Sur ton mobile? le simulateur android par exemple
Non, je n'en ai pas besoin.
Ou un petit gcc-arm par exemple.
Oui, ça ça me suffit, et en plus, ça existe déjà (et ça a été fait par des libristes !).
Pour ton dsp... arg. Il te faut une board (bah oui, les simu cycle accurate existent, mais qu'en interne des boites, et coute méga cher et son méga lent)
Mais c'est quoi une "board" pour toi ? Moi, j'ai déjà mon matos (un téléphone, une beagleboard, un N900, etc) et ça me suffit pour faire marcher mon DSP !
les connecteurs
Quels connecteurs ?!!
un os debug dessus...
Pourquoi ?
J'ai l'impression que tu as une vision complètement formatée par les constructeurs ... "Il faut forcément le kit complet". Je suis d'accord que mon espoir d'avoir de la doc est un peu vain pour l'instant, mais aujourd'hui si j'arrive à reverse-engineerer ces specs, je peux compiler mon propre blob et le faire tourner par le DSP, sans aucun matos ou soft supplémentaire ! Par besoin de connecteur spécial, de debugger spécial ... ! Je ne vois pas ce dont tu veux parler.
Très peu de monde pourraient le faire sur leur temps libre (j'en connais qui en feraient des merveilles).
Là je vais redevenir vulgaire : j'ai _horreur_ des mecs qui me disent ce dont je suis capable ou pas. Franchement, avec tout ce qui existe en libre dans tous les domaines aujourd'hui, je ne vois pas comment on peut continuer à sortir ce genre d'argument débile. (dans le genre de programmation "pointue", j'ai codé des routines de manipulation d'image (blending, ...) pour Enlightenment en Altivec sur PPC, avec prefetch, alignement correct, maximisation de la BP ; je veux bien que coder un DSP soit compliqué, mais quand même).
Mon avis, est que, plus on s'éloigne du monde du pc, plus l'argent qu'il faut sortir pour avoir un env de dev est important, donc moins il y a de gens, moins de support. In fine, tu auras UN gars qui va te pondre un super codec sur ton DSP A, et personne pour le maintenir au bout de 2 ans.
Et alors ? Tu fais dans l'obscurantisme ! "vous en serez pas capables", "vous n'avez pas l'argent", "c'est trop dur pour vous" : aucun de ces pseudo-arguments ne peut être utilisé de manière valable : c'est juste de la dissuasion. C'est tout ce dont j'ai horreur dans le monde proprio, et qui disparaît complètement dès qu'on ouvre le truc.
Donc bon, coder sur DSP, merci, j'ai déjà fait, c'est inchiable, et quand ça marche on n'y touche plus!
Aurais-tu des exemples de programmes sur DSP ? Ça m'intéresse beaucoup, car je vois beaucoup de personnes dire que c'est inchiable, mais personne n'en montre.
A moins, évidement, qu'une norme genre openmax DL ne fournisse les primitives IDCT and co directement dans une belle API, et qu'en dessous ça passe de manière transparente dans les accélérateurs hardware ou dsp. Ca oui, j'y crois. Mais ne travaillant plus dans le mobile, je ne sais pas où ça en est (il y a 2 ans tout le monde en parlait).
Je viens d'aller voir, je ne connaissais pas, mais ça a l'air de s'approcher d'OpenCL. C'est vrai que ça pourrait être une solution qui aiderait à résoudre le problème des codecs. Mais si j'aurais mon côté râleur qui dirait que ça ne change rien à la situation fermée des DSP. Mais bon, au moins, ce sera plus souple.
[^] # Re: ...
Posté par benoar . En réponse au journal Dear Google,. Évalué à 3.
Juste pour préciser, quand je dis "ouvrir", c'est avoir la doc des opcodes, c'est tout. C'est la base, quand même ...
Sur ton mobile? le simulateur android par exemple
Non, je n'en ai pas besoin.
Ou un petit gcc-arm par exemple.
Oui, ça ça me suffit, et en plus, ça existe déjà (et ça a été fait par des libristes !).
Pour ton dsp... arg. Il te faut une board (bah oui, les simu cycle accurate existent, mais qu'en interne des boites, et coute méga cher et son méga lent)
Mais c'est quoi une "board" pour toi ? Moi, j'ai déjà mon matos (un téléphone, une beagleboard, un N900, etc) et ça me suffit pour faire marcher mon DSP !
les connecteurs
Quels connecteurs ?!!
un os debug dessus...
Pourquoi ?
J'ai l'impression que tu as une vision complètement formatée par les constructeurs ... "Il faut forcément le kit complet". Je suis d'accord que mon espoir d'avoir de la doc est un peu vain pour l'instant, mais aujourd'hui si j'arrive à reverse-engineerer ces specs, je peux compiler mon propre blob et le faire tourner par le DSP, sans aucun matos ou soft supplémentaire ! Par besoin de connecteur spécial, de debugger spécial ... ! Je ne vois pas ce dont tu veux parler.
Très peu de monde pourraient le faire sur leur temps libre (j'en connais qui en feraient des merveilles).
Là je vais redevenir vulgaire : j'ai _horreur_ des mecs qui me disent ce dont je suis capable ou pas. Franchement, avec tout ce qui existe en libre dans tous les domaines aujourd'hui, je ne vois pas comment on peut continuer à sortir ce genre d'argument débile. (dans le genre de programmation "pointue", j'ai codé des routines de manipulation d'image (blending, ...) pour Enlightenment en Altivec sur PPC, avec prefetch, alignement correct, maximisation de la BP ; je veux bien que coder un DSP soit compliqué, mais quand même).
Mon avis, est que, plus on s'éloigne du monde du pc, plus l'argent qu'il faut sortir pour avoir un env de dev est important, donc moins il y a de gens, moins de support. In fine, tu auras UN gars qui va te pondre un super codec sur ton DSP A, et personne pour le maintenir au bout de 2 ans.
Et alors ? Tu fais dans l'obscurantisme ! "vous en serez pas capables", "vous n'avez pas l'argent", "c'est trop dur pour vous" : aucun de ces pseudo-arguments ne peut être utilisé de manière valable : c'est juste de la dissuasion. C'est tout ce dont j'ai horreur dans le monde proprio, et qui disparaît complètement dès qu'on ouvre le truc.
Donc bon, coder sur DSP, merci, j'ai déjà fait, c'est inchiable, et quand ça marche on n'y touche plus!
Aurais-tu des exemples de programmes sur DSP ? Ça m'intéresse beaucoup, car je vois beaucoup de personnes dire que c'est inchiable, mais personne n'en montre.
A moins, évidement, qu'une norme genre openmax DL ne fournisse les primitives IDCT and co directement dans une belle API, et qu'en dessous ça passe de manière transparente dans les accélérateurs hardware ou dsp. Ca oui, j'y crois. Mais ne travaillant plus dans le mobile, je ne sais pas où ça en est (il y a 2 ans tout le monde en parlait).
Je viens d'aller voir, je ne connaissais pas, mais ça a l'air de s'approcher d'OpenCL. C'est vrai que ça pourrait être une solution qui aiderait à résoudre le problème des codecs. Mais si j'aurais mon côté râleur qui dirait que ça ne change rien à la situation fermée des DSP. Mais bon, au moins, ce sera plus souple.