antistress a écrit 4417 commentaires

Merci pour la précision :)

Dingue BSD vient juste d'avoir KMS et paf ! Ils dont rootless X dans la foulée.
Les pilotes KMS sous Linux ça fait des années et arrive seulement rootless X (Moblin mis à part) o_O

non, mais il peut appeler ffmpeg pour décoder plus de formats que ceux des plugins natifs si j'ai bien compris.

sinon Pitivi n'a jamais planté chez moi, il ne semble pas que ce soit le cas de Kdenlive d'après ce que j'ai pu lire ?

C'est l'infrastructure de GNOME.

Voir par ex dans la dépêche en cours de rédaction "Spéciale Lennart Poettering : nouvelles versions de systemd et PulseAudio"

J'ai pas retrouvé le rapport de bogue correspondant

Je crois qu'il y a un peu de boulot dans GStreamer avant. Il y a un rapport de bogue ouvert dans Pitivi sur cette fonction

Oui, et seule la transition serait ré-encodée.

J'ai aussi voté pour celle-ci ;)

Rob Clark est positif, notamment sur la doc qu'il a très rapidement survolée et qui répertorie notamment les erreurs (un des trucs que les devs de Nouveau ont apprécié avoir de Nvidia récemment, ça fait gagner du temps)
http://www.phoronix.com/forums/showthread.php?96560-Broadcom-Open-Sources-VideoCore-IV-3D-Graphics-Stack&p=401701#post401701

Je ne suis pas expert, mais je n'attends du BIOS que l'initialisation, et c'est précisément ce que Intel ne fournit pas…

Quitte à être un peu réducteur, au final on a Red Hat vs Canonical, avec Debian qui fait pencher la balance. C-à-d que dans la configuration présente des forces en présence, Debian a un pouvoir phénoménal, celui de faire les rois choix.

J'ai un article sous le coude depuis décembre, je vais finir par le publier sur mon blogue, stay tuned ;)

VAAPI c'est comme Mesa qui implémente OpenGL si tu veux, après il faut que les logiciels utilisent cette bibliothèque.
Chaque logiciel peut appeler la VAAPI donc, mais comme sous GNOME on a un paquet de logiciels qui sous-traitent le traitement A/V à GStreamer, c'est particulièrement intéressant que GStreamer soit capable d'utiliser la VAAPI comme ça tous les logiciels de l'environnement en profitent.
Cf http://fr.wikipedia.org/wiki/Video_Acceleration_API#Logiciels_support.C3.A9s

J'ai pas essayé tout court, même pas sus Ivy Bridge. Tu utilises quoi comme logiciel pour tester ?

OpenCL 1.2 ça sera pour Haswell, Ivy Bridge c'est OpenCL 1.1 max a priori

Ceci étant dit, j'ai du mal à être dur avec la boite qui a certainement le meilleur niveau de collaboration avec le monde Libre

Attention, Intel n'est pas du tout un bon copain du monde Libre, c'est seulement la division graphique d'Intel mais toutes les divisions d'Intel ne sont sont pas au même niveau, bien au contraire.
V. par exemple https://www.fsf.org/campaigns/free-bios.html (que j'ai traduit dans ce billet http://libre-ouvert.toile-libre.org/index.php?article182/choisir-un-ordinateur-portable-machine-de-guerre-ou-machine-de-liberte) :

La société la moins coopérative est Intel, qui a commencé un projet bidon de BIOS « open source ». Le logiciel regroupe toutes les parties sans intérêt du BIOS, sans les parties importantes. Il ne fonctionne pas et ne nous aide en rien à obtenir un BIOS fonctionnel. Il s'agit juste d'une distraction. Au contraire, AMD s'est montré coopératif en publiant des gros morceaux du code source de leur BIOS et en permettant à ses experts techniques de nous aider.

Je ne critique pas gratuitement LibreOffice que je trouve formidable et que j'utilise exclusivement, mais je voulais juste partager cette expérience personnelle :
Sur ma machine perso sous Debian Sid avec LibreOffice du dépôt Sid et Firefox Aurora du dépôt Mozilla, Firefox Aurora (avec pas mal d'extensions et d'onglets ouverts, mais pas de plugins type Flash) ne plante quasiment jamais (je ne me souviens pas d'un plantage) alors qu'il arrive que LibreOffice plante de temps en temps (sans conséquences, grâce à la boite de dialogue de récupération qui fait le job).
Là ça vient de m'arriver avec 3 petits documents ouverts, pourtant créés par moi-même sous LibreOffice.
J'espère que ce point s'améliorera au fur et à mesure de l'appropriation et du nettoyage du code.

Merci pour l'info.
La table ronde sera t-elle filmée et le film, mis en ligne ? Ça serait super de faire partager ce débat. Merci !

Donc le pilote pour Intel Gen3 gérerait OpenGL ES ?

À long terme, on pourra utiliser de l’OpenGL « classique » sous Wayland.

D'ailleurs, peut-on en savoir plus à ce sujet ?

Sauf erreur de ma part, le Gen5 est en fait une légère évolution du GMA X4500HD donc tu as en gros les caractéristiques d'un Gen4 de dernière génération : transform and lighting, architecture de shaders unifiés avec le Shader model 4.0, DirectX 10.1 et OpenGL 2.1 (sous réserve de l’implémentation par les pilotes).

J'ai un netbook avec GMA950 (Gen3 : DirectX 9.0c, OpenGL 1.4, Pixel Shader 2.0) : j'espère qu'il pourra faire tourner Wayland un jour ?

Intéressant, mais c'est possible même avec une bibliothèque C différente (j'imagine que oui et que c'est à la compilation que les changement s'opèrent), un serveur d'affichage différent (SurfaceFlinger) et surtout les API propres à Android qui ne suivent pas nécessairement la norme POSIX ?

En même temps tu dis toi même que c'est 16 correctifs / 15 j de travail "seulement"

Oui.

C'est pas contradictoire avec ce que tu écris ?

NVIDIA fourni un driver codé vite fait pour Android, faut que ça marche. Ensuite Google demande à NVIDIA de faire un effort et de rendre ce support disponible upstream pour diminuer les différences entre Linux et le noyau Android. L'avantage de diminuer les différences, c'est de diminuer les risques de problèmes lorsque android se re-base sur un nouveau noyau. Google doit vraiment pas vouloir trop diverger et c'est très bien!
Comme Google a de l'argent et doit probablement être prêt à payer, NVIDIA est prêt à dépenser cet argent pour faire le travail demandé. Tout simplement.

Ça ne colle pas pour moi avec le fait que les autres fabricants de cœurs graphiques pour l'embarqué en ont rien à battre des pilotes du noyau si Google avait vraiment du pouvoir à ce niveau… Non, je pense que le fait que NVIDIA soit challenger sur ce marché les pousse à se différencier tout simplement, bref que c'est une stratégie NVIDIA pure

Ce travail de NVIDIA vient d’une idée simple : les Tegra K1 étant basés sur des cœurs graphiques Kepler, qui sont déjà pris en charge par Nouveau, leur ajout devrait être assez simple. De plus, Linus n’autorisant généralement pas deux pilotes concurrents pour le même matériel, il est assez intéressant de voir que NVIDIA a décidé de réaliser la prise en charge totalement en amont, et de ne pas se limiter à l’arbre Android pour lequel un pilote existe déjà.

Je ne pige pas : Nouveau et Android, ça fait bien deux pilote pour le même matos ?!

Nous pouvons spéculer que ce travail est le fruit de la volonté de Google de rendre le noyau Linux pour Android aussi proche que possible du noyau Linux original.

Je vois pas le rapport entre les stratégies de NVIDIA et de Google ?

Pour les pilotes propriétaires c'est tout simplement de pouvoir supporter leur matériel sous Linux de manière satisfaisante pour leurs clients professionnels. Cela nécessite un driver qui supporte toutes les fonctionnalités OpenGL mais aussi qui est certifié avec les gros logiciels (CATIA, Maya …). Si AMD voulait faire cela avec les drivers libres il leur faudrait embaucher plusieurs centaines de personnes pour travailler sur le driver libre (on ne peut pas partager les équipes entre le driver propriétaire et le driver libre). Il faudrait donc un investissement considérable pour AMD pour un retour nul ou presque. Leurs clients professionnels ne s'intéressent pas de savoir si le driver est libre ou pas, ils veulent juste une solution rapide et à un prix raisonnable.

https://linuxfr.org/news/entretien-avec-jerome-glisse-developpeur-des-pilotes-graphiques-radeon-pour-red-hat