motörhead a écrit 13 commentaires

Je trouve que ce commentaire est un peu nébuleux.

En plus, je suis beaucoup plus intéressé par les développements que connait Xorg que par le monde (obscur s'il en est) de la libc, auquel je ne pane strictement rien.

Pour la libc le processus de développement est toujours le même, et reste assez simple (juste 2 étapes en fait) :
- quelqu'un envoie un patch pour la libc
- le patch est refusé par le mainteneur

Pire que ça, il insinue qu'il existe des employés INRIA qui bossent !

Oui mais toi tu n'es pas une fille dans un monde de geek en manque.

Parce que cet 'article' est faux. On peut regarder le header de l'API XvMC qui confirme bien qu'il fait plus que juste MC (ça parle d'iDCT, de CSC et de MC) :
http://cgit.freedesktop.org/xorg/proto/videoproto/tree/XvMC.(...)

Sauf que justement XvMC est limité au MPEG-2 et, pire, qu'il ne prend en charge que le motion compensation

Ah la la, quel beau lancer de troll !

Malgré son nom mal choisi, XvMC fait plus que juste MC (il fait aussi l'iDCT et CSC). Je t'invite a te renseigner à la source universelle et unique de connaissance internetienne : http://en.wikipedia.org/wiki/X-Video_Motion_Compensation

Il faut être honnête, si tu as déjà fait de l'audio sous windows, ca skip parfois.

Le noyau temps réel de linux (on parle ici de temps réel dur), avec les bonnes conditions (matos pas complètement rachitique, pas de drivers qui font n'importe quoi) te donne l'assurance que ça fonctionnera 100% du temps (et pas 99.99%), à savoir que ta requête audio sera traitée dans les XX microsecondes à tous les coups.

Windows et MacOS ne peuvent pas donner cette garantie.

On se connait pour que tu saches que je n'ai pas besoin du patch RT ?


Ben en l'occurence, tu utilises le patch RT mais ton temps réel est en fait "cassé" par la présence d'un driver video accéléré, et donc ton noyau n'est pas temps réel.

On constate aussi que tu n'as remarqué aucun problème lié à cette utilisation conjointe, en tout cas tu ne t'en plains pas dans ton journal.

En conséquence, si ton noyau n'est pas temps réel et que tu n'as remarqué aucun problème c'est que tu n'en avais pas besoin, du temps réel.

Ah oui, les drivers graphiques libres ne sont pas RT-safe non plus.

Ah oui, j'ajoute que si on tient vraiment à utiliser X sur un système RT, on peut utiliser le driver vesa, qui s'il ne fait pas des étincelles permet d'éviter ces problèmes puisqu'il ne fait pas d'accélération non plus.

2) je ne cherche pas du temps réel dur, j'utilise jack pour de l'enregistrement musicaux, et le système sonore de Linux est tellement pourri que pour avoir des perf potables, il faut le noyaux RT, et pour ne devrais-je pas utiliser la 3D en RT ?


Par exemple, si un driver fait un gros DMA qui bloque le bus pendant quelques millisecondes, ton CPU sera bloqué pour ses acces mémoire et tu peux alors rater une ou des échéances RT. Pour faire du RT il faut que tous les drivers soient adaptés (i.e. qu'ils promettent de pas faire de gros DMA d'un coup par exemple). A ma connaissance peu le sont, et les pires sont les drivers graphiques pour ça.

Ah oui, les drivers graphiques libres ne sont pas RT-safe non plus.

Il semble que AMD va donner des docs 3D très bientôt:
http://www.phoronix.com/scan.php?page=article&item=amd_t(...)

Ne t'inquiète pas, il y a des tas de gens qui font des conneries énormes et qui ne s'en rendent jamais compte.

Allez, reprends un coup de TF1 et arrête ces délires humanistes.

Franchement s'ils arrivent à avoir l'aval de 1700 dévelopeurs, ça sera une partie de plaisir de convaincre trolltech de passer à la GPL3 en comparaison.