benoar a écrit 4229 commentaires

Avoir plus d'utilisateurs comme ça ne changera rien pour les specs, vu qu'ils installeront le driver proprio et gueuleront quand il ne marchera pas. Je ne suis pas un fan des "parts de marché" de linux : ça ne m'intéresse pas.

Moi ça me dérange pas qu'un idiot qui veut tout sans en avoir rien à foutre du libre retourne sous Windows ...

Oui ça me dit quelque chose, mais je crois que c'était un transporteur privé (UPS ou autre).

Comme dit plus haut ils n'ont pas le droit, mais je pense que certains doivent quand même "l'intercepter" pour leur poche ... (histoire vécue /o\)

Ha bah voilà, c'est ça que j'aime pas : beaucoup de monde fait la confusion entre le driver libre et proprio, et après tout le monde raconte que le driver libre plante. Non, pas du tout !

Avec les pilotes libres ? C'est hallucinant, moi, niveau stabilité, je (quasiment) jamais eu aucun plantage. Après, niveau lenteur, du fait du manque d'accel, peut-être.

En quoi ils ont une version spéciale de Windows ?

Je parie 100 balles et un mars que ce truc sera fermé et qu'on ne pourra pas le "libérer". C'est con, pour ce prix j'aurais bien aimé faire mumuse dessus.

(en plus je suppose que c'est un ARM avec linux ... vive le respect de la GPL)

Moi j'aimerais bien qu'on me cite un matériel quelconque qui a un Windows modifié aux petits oignons. Bon, c'est pas ma spécialité, donc j'ai peut-être loupé certains périphériques évidents, mais dans ma mémoire je n'en ai jamais vu.

Je parlais des utilisateurs de Nvidia. Et très peu sont là pour aider à tester nouveau. Ce que je trouve dommage pour l'avancée du libre dans ce domaine.

Étrange ton bug ...
De mon expérience, les ATI ont toujours été plutôt de bonnes expériences, à part niveau perf, mais ça ne me gène pas en 3D. D'après les avis que j'ai entendu, ton cas est plutôt l'exception que la règle. Mais c'est clair que ça fait chier d'être l'exception.

Je ne suis pas un gamer, donc les grosses perfs ... Je joue à des "petits" jeux en 3D avec ma HD3200 intégrée. C'est arrivé dans le driver radeon il n'y a pas très longtemps (genre 2 mois) mais ça marche plutôt pas mal.

Après, j'ai l'impression que t'as eu une mauvaise expérience avec une HD5xxx, qui est sorti il y a à peine quelques mois je rappelle, et que tu veux te venger sur ATI ... Et quand je te vois dire "qui permette de jouer à des jeux récents" et que tu achètes le tout dernier monstre sorti, je me dit que tu es peut-être du genre acheteur compulsif. Je ne dis pas que c'est mal, mais n'espère pas que toutes tes envies soient satisfaites sous linux parce que tu achètes le haut de gamme dernier cri.

À une époque, avoir du matos supporté un an après sa sortie c'était génial. Aujourd'hui, on a pris l'habitude que ce soit supporté out of the box, mais comme le montre ce genre de débat, tout n'est pas encore au point dans tous les domaines, surtout ceux dont les constructeurs sont très peu coopératifs quant aux specs de leur matos.

Oui mais eux ne gueulent pas (ou moins fort) par rapport à ceux de nvidia, et font pas chier en disant "ouai mais notre driver proprio il est vachement trop mieux, cassez vous le cul pour le faire marcher !".

s'adapter au driver proprio ? personne n'a parle de ca ...

Heu, ça avait pas mal gueulé du côté de Fedora au point qu'il ont failli livrer un vieux Xorg pour que le driver nvidia marche, et puis chez Ubuntu j'imagine que ça gueule très fort quand le driver nvidia casse. Bref, oui, le libre s'adapte au proprio dans ces cas, et je trouve ça très dommage.

Franchement, comme déjà indiqué plus haut, les "seuls" problème du pilote libre, c'est les perfs, et éventuellement le support du matos récent. Niveau stabilité, je dirais même que Nvidia est quand même connu pour avoir quelques problèmes à ce niveau.

J'ai l'impression que beaucoup de gens confondent le driver proprio ATI et le libre (radeon), qui n'ont rien à voir niveau support, perfs et stabilité (le proprio gagne dans les deux premiers cas, mais le libre gagne largement dans le 3è ... et en plus, au niveau de la liberté).

Enfin bon, le début de ton commentaire montre bien le respect que tu as pour les gens qui ne pensent pas comme toi ...

T'as bien installé spamassassin ?

Tiens d'ailleurs ce serait encore plus clair comme ça :
import csv
for prenom, nom, code in csv.reader(file("monfichier.csv")):
  print code + prenom[0] + nom

Oui, je suis lourd, mais bon :

import csv
for x in csv.reader(file("monfichier.csv")):
  print x[2] + x[0][0] + x[1]


Que je trouve, comme d'hab, plus lisible.

Encore une fois, je ne demande pas à ce qu'ils filent leur sources ! C'est exactement la fausse conclusion qui tombe à chaque fois qu'on parle des drivers Nvidia ... Non, je ne veux pas les obliger à "libérer" un travail qu'ils ont le droit de mettre sous la licence qu'ils veulent !

Ce que je veux, c'est qu'ils ouvrent l'ISA, bref, une documentation qui explique comment _s'interfacer_ avec le bouzin. Ce qui serait pour moi tout à fait normal. Point de vue utilisateur, ce qui est fait actuellement serait exactement comme te filer une boîte noire sans bouton, c'est complètement inutile.

OK, merci pour ces infos. Je comprend mieux maintenant ton besoin d'un kit complet. Par contre, je continue de penser que c'est une fausse excuse, si tu l'utilises comme argument contre l'ouverture des DSP.

Pour la standarisation des interfaces, oui, c'est toujours une bonne chose. Mais je dirais que ce n'est pas assez souple pour les besoins actuels, et qu'un accès direct au DSP serait quand même vachement plus cool.

J'en ai entendu parler ici :
http://www.armadeus.com/francais/produits-cartes_microproces(...)
Des kits à 100/200€ quoi. Par contre, je ne sais pas trop à quelle puissance ça correspond.

"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.

Rhaa, injonctions bien sûr.
Le pire c'est que je suis moi-même sur la page que tu cites ...

Bon, effectivement, c'est abusé de ma part de dire qu'on achète que des puces "toutes prêtes" et qu'on ne fond rien : TI ou Freescale fondent effectivement des IPs. Et fournissent un gros travail d'intégration.

Ce que je souhaitais préciser, c'est que ces IPs sont des trucs relativement "standards", comme le ARM ou le C64. Et aussi que moi je ne me fous pas de ce que ne fournit pas le toolkit : je suis un bidouilleur libriste qui veut savoir ce qu'il y a "derrière" (bon, là je m'écarte du sujet pour relancer mon idée, déjà citée plus haut, d'ouvrir un peu plus ces trucs).

Parce que le problème d'accélération dont on parle ici est exactement ça : quelle est la limite entre ce qu'"on" peut reprogrammer ou non (sachant qui si tu as un gros porte-feuille, je pense que tu peux "tout" reprogrammer, car tu peux par exemple fondre tes propres IPs ... oui, j'ai dit un très gros porte-feuille).

Mon argument était que, les DSP étant reprogrammable (d'ailleurs j'ai du mal à voir ton IP de DCT en interne du DSP : que veux tu dire exactement par là ? genre un peu comme on intègre du MMX dans un CPU ?), pour moi, l'argument du "on ne peut pas faire autre chose que du H264 car c'est câblé en dur" est caduc. Car n'importe qui avec des compétence sur un C64 pourrait te refaire la même chose pour VP8 ou Theora (des compétences et "un peu" de temps, certes, mais comme dans n'importe quel domaine ou le libre avance).

Toi, tu pars du principe que comme le toolkit ne présente qu'un accès "haut niveau" au décodage H264, en gros, c'est câblé "en dur" et on ne peut rien faire d'autre. J'ai bien reformulé ton idée ?

Alors, d'un point de vue pragmatique, je suis d'accord avec toi. Mais d'un point vue même pas théorique, mais simplement pratique, c'est débile car un DSP est reprogrammable par définition : c'est toi-même avec ton linux qui va même charger le programme du DSP en mémoire !

Bref, pour moi, la barrière de la fermeture du DSP est complètement artificielle, et pourrait facilement sauter si les DSP retrouvaient leur vrai nature.

Je remarque aussi qu'on a le même problème avec les FPGA. Je ne sais pas si les constructeurs se rendent compte que s'ils ouvraient un peu plus leur produits, ils auraient un public énorme en plus (ok, ce n'est qu'un avis de libriste ...).

(sauf problèmes de transit éventuels)

Effectivement, vu l'utilisation de ton forfait Internet, si tu as un problème de transit, tu risques d'exploser ton forfait /o\