Journal Débat autour des pilotes graphiques à moitié libres.

Posté par Olivier Esver (site web personnel) le 03 juillet 2010 à 16:26.

Étiquettes :

juil.

2010

Ce journal fait suite à l'annonce de Qualcomm à propos de ses pilotes libres.

En fait tout le pilote n'est pas libre, une partie l'est car intégrée au kernel, c'était d'ailleurs le but de l'annonce pour qu'ils soient intégrés dans le noyau pour suivre l'évolution de celui-ci.

Et une autre partie est fermé, un beau blob binaires comme nous les aimons tant.

Suite à cela, Dave Airlie, employé de Red Hat travaillant sur les pilotes graphique s'est exprimé sur ce qu'il pensait de ces solutions à moitiés libres.
En gros il ne veut aucune intégration de la partie libre si tout n'est pas libre :
"If you aren't going to create an open userspace driver (either MIT or
LGPL) then don't waste time submitting a kernel driver to me."

Je vous invite à lire de vous même les articles et surtout le mail de Dave Airlie, voir suivre le débat sur la liste dri-devel.

Ce qui peut être inquiétant est que cela semble devenir la tendance de faire du à moitié libre pour l'annonce et en fait c'est un blob. Je trouve ça dommage car le pilote "libéré" est celui des téléphones Android Nexus One et HTC Desire.

Les articles sur phoronix :
Qualcomm Releases Open-Source 2D/3D Kernel Driver
[http://www.phoronix.com/scan.php?page=news_item&px=ODM4O(...)]
Qualcomm's Open Kernel Driver Leads To A Dirty Mess
[http://www.phoronix.com/scan.php?page=news_item&px=ODM4O(...)]

Et pour ceux qui veulent aller directement au mail de Dave Airlie :
http://lists.freedesktop.org/archives/dri-devel/2010-July/00(...)

PS: oui je sais, j'aurai du le poster hier, on aurai pu avoir de superbes débats de vendredi avec des nvidia suxxx, amd rullz et intel rullz sauf poulsbo qui suxx

# Nokia N900

Posté par Olivier Esver (site web personnel) le 03 juillet 2010 à 16:31. Évalué à 8.

Vu que dans ce journal j'ai parlé de téléphones, et que souvent on nous rétorque que le Nokia N900 est mieux car plus libre, j'aurai aimé savoir ce qu'il en est des pilotes graphiques, car il me semble qu'il y a une puce PowerVR, donc Imagination Technologies donc le plus souvent un blob binaire.

Ce qui veut dire qu'on ne peut avoir une base libre (comme la plupart des téléphones Android).

J'aurai aimé savoir ce qui n'est pas libre sur ce téléphone (graphique ? wifi?)
S'il y a un problème, il y a une solution; s'il n'y a pas de solution, c'est qu'il n'y a pas de problème.
- [^] # Re: Nokia N900
  
  Posté par Loic Dreux le 03 juillet 2010 à 17:05. Évalué à 10.
  
  Tout ce qui est en rouge sur ce schema : http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/(...)
  - [^] # Re: Nokia N900
    
    Posté par Gabin le 03 juillet 2010 à 17:17. Évalué à 10.
    
    Ah oué, c'est clair que c'est mieux que sous l'Iphone...
    
    Y a t-il un tableau équivalent pour Androïd? Afin de voir à quel point ils se foutent de notre gueule avec leur prétendue ouverture et que les geeks libristes arrêtent de s'acharner bêtement sur Apple qui lui, ne joue pas de double discours!
    - [^] # Re: Nokia N900
      
      Posté par Ph Husson (site web personnel) le 03 juillet 2010 à 17:40. Évalué à 10.
      
      Un tableau aussi détaillé ça m'étonnerait, mais j'vais tacher de faire ça à la louche par comparaison avec le N900, et je me base sur la plateforme Snapdragon (les msm7k ont plus de trucs fermés)
      Comme le N900:
      -OpenGL ES fermée (du moins l'implém hard, l'implém soft est libre mais bon...)
      -Le boot loader est fermé (il fait aussi flasher, et l'appli côté ordi est libre). À noter que Qualcomm a annoncé (et sorti.) un bootloader alternatif libre.
      -Tout ce qui est gestion GSM est fermé
      -Ce qui tient de la PIM est fermé (à comparer à funambol, le calendrier, libaccounts etc): Il s'agit de google talk/mail/calendar principalement, qui n'ont pas vraiment d'alternatives libres. (google mail a k9mail et google talk extrempp mais bon.. ça reste maigre)
      -Ce qui est géolocalisation par GSM est fermé
      -Le "wizard" du début est bien fermé (il ne sert qu'à rentrer son compte google, sans apps google forcement ça va pas loin ...)
      
      Contrairement au N900:
      -Un point que je ne vois pas sur ce schéma c'est le market, sous android il est bien proprio, mais il y a plein de markets alternatifs tout à fait utilisable.
      -La partie localisation dans maemo fait aussi réference au GPS je pense, celui ci est ouvert/ouvrable sous android
      -Tout ce qui est multimedia est ouvert/ouvrable. (Il existe des implémentations alternatives fermées quand même pour gérer plus de formats, genre sur l'acer liquid qui rajoute le support de formats tels que le divx ou le WMV (à l'heure actuelle, l'android libre ne gere que le mp4/H264 et H264))
      
      Par contre, ils parlent de tout ce qui est graphismes et sons, je n'ai strictement aucune idée de la licence utilisée pour ceux là dans android. A priori c'est au moins redistribuable librement
      
      Voilà, c'est à peu pres tout ce qui me passe par l'esprit en regardant ce graph.
      
      PS: À noter que partout où je dis android ici, c'est Android/Snapdragon, Android/msm7k est bien plus fermé, et je ne connais pas du tout Android/Omap ni Android/Samsung (ou autre.)
# Suite du journal

Posté par Olivier Esver (site web personnel) le 03 juillet 2010 à 17:44. Évalué à 10.

Dave Airlie vient de poster un autre message sur son blog :
[http://airlied.livejournal.com/73337.html]

Il réponds à plusieurs questions telles que
Qu'est ce que l'industrie de l'embarquée obtient de linux ?
Qu'essayent ils de cacher en espace utilisateur ?
Pourquoi devraient ils réécrire leurs pilotes ?
...
S'il y a un problème, il y a une solution; s'il n'y a pas de solution, c'est qu'il n'y a pas de problème.
- [^] # Re: Suite du journal
  
  Posté par benoar le 04 juillet 2010 à 17:47. Évalué à 2.
  
  Très bon post.
  Un autre, sur la ML, à propos de l'avenir de l'ouverture des GPU embarqués actuellement sur le marche (fin du mail) : http://lists.freedesktop.org/archives/dri-devel/2010-July/00(...)
  
  Pas très optimiste, mais malheureusement assez réaliste.
  - [^] # Re: Suite du journal
    
    Posté par Nicolas Boulay (site web personnel) le 04 juillet 2010 à 20:10. Évalué à 3.
    
    Vivement que opengraphics sorte une carte :) Le problème restera le pipeline fixe quand opengl ES 2.0 qui devient le standard utilise uniquement des shaders :/
    "La première sécurité est la liberté"
    - [^] # Re: Suite du journal
      
      Posté par BAud (site web personnel) le 04 juillet 2010 à 20:44. Évalué à 3.
      
      yen a 25 des OGD1 de sorties :
      http://www.osnews.com/story/23473/Timothy_Miller_Michael_Dex(...)
      - [^] # Re: Suite du journal
        
        Posté par Nicolas Boulay (site web personnel) le 04 juillet 2010 à 22:25. Évalué à 4.
        
        Malheureusement, ce n'est que de version de dev avec un gros FPGA couteux. Il faudrait attendre des versions "asic" moins couteuse et plus performante.
        "La première sécurité est la liberté"
# C'est pas mieux..

Posté par Grunt le 03 juillet 2010 à 19:59. Évalué à 2.

.. avec Ati. Depuis la séparation par Debian des blobs binaires du noyau, on s'aperçoit que pour faire tourner une carte AMD/Ati, il faut un bon gros blob binaire:
http://packages.debian.org/fr/sid/firmware-linux-nonfree
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
- [^] # Re: C'est pas mieux..
  
  Posté par Olivier Esver (site web personnel) le 03 juillet 2010 à 20:50. Évalué à 10.
  
  La différence chez les pilotes libres ATI, c'est que le pilote est libre, seul le microcode ne l'est pas.
  
  Chez ATI on a donc accès à toutes les fonctions de la carte graphique.
  
  Là il n'y a rien de tout ça, ils veulent juste que leur partie intégrée au noyau, qui ne fait pas grand chose, soit inclue à celui ci pour qu'ils n'aient pas à suivre les évolution.
  
  Pour moi, le microcode fait partie du hardware, celui ci n'étant pas libre, le microcode ne l'est pas non plus.
  Mais je me trompe peut être sur mon interprétation de ce qu'est ce microcode.
  S'il y a un problème, il y a une solution; s'il n'y a pas de solution, c'est qu'il n'y a pas de problème.
  - [^] # Re: C'est pas mieux..
    
    Posté par Guillaume Knispel le 03 juillet 2010 à 21:16. Évalué à 8.
    
    Les microcodes acceptés par la communauté Linux ne tournent pas dans le CPU. La situation serait certes encore meilleure si tous les coprocesseurs étaient complètement documentés et avec des toolchains libres, ainsi que des firmwares libres, mais la situation actuelle n'est guère différente de s'il y avait une ROM contenant les microcode au lieu que cela soit le CPU qui l'upload. (Mais ça reste quand même triste de savoir qu'on pourrait améliorer beaucoup de choses si les docs et toolchains étaient publique ; en ce moment je bosse sur un design hard et je me prend parfois à rêver à comment je pourrais l'améliorer si je pouvais modifier/réécrire un FW -- et malheureusement je ne peux pas...)
- [^] # Re: C'est pas mieux..
  
  Posté par benoar le 04 juillet 2010 à 17:38. Évalué à 4.
  
  Bon, je ne vais pas répéter ce qu'ont déjà dis les autres plus haut (ça tourne sur la carte, et _tout_ le reste est libre, ce qui est quand même énorme comparé à ce que c'est). Je vais juste ajouter que ce sont des firmware pour pouvoir modifier quelques petits paramètres de la carte : la majorité font entre 2 et 5ko, et quelques-uns 20ko. Et ce n'est pas spécifique à ATI : ya la même chose chez NVidia, sauf que c'est flashé sur un mémoire non-volatile, et que donc on n'a pas à les charger à chaque fois (oui, économie de bouts de chandelles ...)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.