Vu que personne n'a l'air d'avoir été regarder le code, voyons ce qu'il y a avec un rapide coup d'œil.
Tout d'abord, le driver fourni est une pile OpenGL ES1.1 et 2.0 pour Android 4 seulement. Elle a l'air entièrement maison, donc aucune réutilisation de Mesa ou autre code déjà libre. Elle fait un peu plus de 300 000 lignes (cf sloccount), dont plus de 80% de C, avec quand même 40 000 lignes d'assembleur (!). La majeure partie se trouve dans brcm_usrlib/.
Cette histoire d'assembleur m'intrigue. Quand on regarde de près (brcm_usrlib/dag/vmcsx/helpers/), ce sont des routines de traitement d'image (blit, mask, or/xor, transposition, flip, conversion yuv/rgb, etc dans vc_image/) ou des optimisations de routines « classique » (crc, génération d'aléa, statistiques, opérations mémoire pour vclib/) principalement écrites en utilisant des instructions NEON (instructions SIMD). On voit donc que ça permet d'avoir des routines rapides, mais pour l'instant on reste entièrement sur le CPU.
À propos de calcul « soft » (par opposé au GPU), on voit que l'OpenVG est codé entièrement sur le CPU également (vmcsx/middelware/khronos/vg/). Sinon, une grosse partie des autres « middleware » sont apparemment pour la gestion de shaders. Il y a également un compilateur de shaders.
Une grosse partie du code va dans l'interface avec le GPU (vmcsx/interface/), où ils réinventent un système d'IPC à leur sauce.
Niveau code, c'est moyen (des ifdef partout, pas de convention de codage) mais j'ai vu pire. Je ne connais pas le système de build d'Android, donc je ne me prononcerait pas sur la facilité de compilation.
Bref, une pile « standalone », qui ne réutilise rien de l'existant, qui a plein de choses spécifiques à cette puce (c'est normal pour un driver, mais là ça fait beaucoup), je ne pense pas que ça va intéresser grand monde, à part ceux qui ont des RPi et beaucoup de temps à y investir. Ils réinventent une grosse partie de Mesa, et ça n'est pas demain la veille à mon avis qu'on verra le support de cette puce à ce projet. À part peut-être les implémentations NEON qui pourraient éventuellement être intéressantes pour un moteur OpenGL ES software pour ARM, je ne vois pas grand chose à récupérer.
Je n'ai pas des masses regardé la doc, mais elle est assez « courte » (111 pages) pour une spécification. Je ne suis pas non plus un spécialiste des cartes graphiques, donc je ne sais pas si elle est bonne ou pas.
Donc voilà, c'est bien de sortir du code libre, mais certains codes ont plus d'intérêts que d'autres, en fonction de leur intégration à l'existant. Là, je ne vois pas beaucoup l'intérêt. Ce qui fait que je n'irai pas jusqu'à dire merci à Broadcom, surtout connaissant leur passif, même si on ne va pas non plus les dénigrer pour avoir sorti ce code.
# Regardons le code
Posté par benoar . En réponse au journal Donc maintenant Broadcom aime l'open source et les specs ouverte ?. Évalué à 10.
Vu que personne n'a l'air d'avoir été regarder le code, voyons ce qu'il y a avec un rapide coup d'œil.
Tout d'abord, le driver fourni est une pile OpenGL ES1.1 et 2.0 pour Android 4 seulement. Elle a l'air entièrement maison, donc aucune réutilisation de Mesa ou autre code déjà libre. Elle fait un peu plus de 300 000 lignes (cf sloccount), dont plus de 80% de C, avec quand même 40 000 lignes d'assembleur (!). La majeure partie se trouve dans brcm_usrlib/.
Cette histoire d'assembleur m'intrigue. Quand on regarde de près (brcm_usrlib/dag/vmcsx/helpers/), ce sont des routines de traitement d'image (blit, mask, or/xor, transposition, flip, conversion yuv/rgb, etc dans vc_image/) ou des optimisations de routines « classique » (crc, génération d'aléa, statistiques, opérations mémoire pour vclib/) principalement écrites en utilisant des instructions NEON (instructions SIMD). On voit donc que ça permet d'avoir des routines rapides, mais pour l'instant on reste entièrement sur le CPU.
À propos de calcul « soft » (par opposé au GPU), on voit que l'OpenVG est codé entièrement sur le CPU également (vmcsx/middelware/khronos/vg/). Sinon, une grosse partie des autres « middleware » sont apparemment pour la gestion de shaders. Il y a également un compilateur de shaders.
Une grosse partie du code va dans l'interface avec le GPU (vmcsx/interface/), où ils réinventent un système d'IPC à leur sauce.
Niveau code, c'est moyen (des ifdef partout, pas de convention de codage) mais j'ai vu pire. Je ne connais pas le système de build d'Android, donc je ne me prononcerait pas sur la facilité de compilation.
Bref, une pile « standalone », qui ne réutilise rien de l'existant, qui a plein de choses spécifiques à cette puce (c'est normal pour un driver, mais là ça fait beaucoup), je ne pense pas que ça va intéresser grand monde, à part ceux qui ont des RPi et beaucoup de temps à y investir. Ils réinventent une grosse partie de Mesa, et ça n'est pas demain la veille à mon avis qu'on verra le support de cette puce à ce projet. À part peut-être les implémentations NEON qui pourraient éventuellement être intéressantes pour un moteur OpenGL ES software pour ARM, je ne vois pas grand chose à récupérer.
Je n'ai pas des masses regardé la doc, mais elle est assez « courte » (111 pages) pour une spécification. Je ne suis pas non plus un spécialiste des cartes graphiques, donc je ne sais pas si elle est bonne ou pas.
Donc voilà, c'est bien de sortir du code libre, mais certains codes ont plus d'intérêts que d'autres, en fonction de leur intégration à l'existant. Là, je ne vois pas beaucoup l'intérêt. Ce qui fait que je n'irai pas jusqu'à dire merci à Broadcom, surtout connaissant leur passif, même si on ne va pas non plus les dénigrer pour avoir sorti ce code.