Untitled attachment

Notices where this attachment appears

1. Embed this notice
   Avril (dlb@mamot.fr)'s status on Thursday, 24-Apr-2025 22:13:43 JST Avril

   Retailleau qui decrit le fn comme un parti de gauche ça pique les yeux.

   Il se passe quoi en vrai là ?

   On est en état de sidération ou on à abandonné au fond de nous?

2. Embed this notice
   Alyssa Rosenzweig (alyssa@eldritch.cafe)'s status on Sunday, 01-Dec-2024 02:03:17 JST Alyssa Rosenzweig

   Je viens de lire cet article : https://catfox.life/2024/11/29/the-complexities-of-enabling-opencl-support/

   Je voudrais donner un peu de contexte pour la situation. Ce n'est pas le résultat d'un développeur téméraire d'Intel qui a décidé d'ajouter des dépendances aléatoires à cause de la paresseuse.

   Je ne travaille pas pour Intel, mais je suis peut-être la responsable de ce changement. Bien sûr que des ingénieurs d'Intel ont tapé le changement et ils sont d'accord avec les implications, mais le projet de pousser OpenCL, c'est à moi, et je ne le regrette pas. Si vous voulez blâmer quiconque, blâmez-moi.

   OpenCL est le standard pour la computation accélérée sur les GPUs. Même si un projet utilise SyCL (par exemple), le pilote OpenCL est la fondation sous les APIs abstraits. Si on veut que les pilotes libres soient compétitifs, la prolifération des pilotes OpenCL d'une haute qualité est essentielle. Ce fait a plusieurs implications pour les logiciels libres.

   1. Si une distribution de Linux inclut déjà nos pilotes, le changement en question ne pose aucun problème. On veut que toutes les distributions y arrivent. La plainte dans ce cas vient d'une distribution qui n'a jamais inclut les pilotes d'OpenCL. Pour un système général, ce manque est un problème, un obstacle au but susdit. Naturellement, je ne suis pas heureuse qu'une mainteneuse ait besoin de déboguer des problèmes de big endian. Pourtant, le problème existait déjà loin des yeux.

   2. Il faut que les pilotes d'OpenCL soient excellentes. Si ces pilotes ne suffisaient pas pour nos propres buts, ils ne suffiraient pas pour les buts de nos utilisateurs non plus. C'est-à-dire, les développeurs de Mesa doivent "manger notre propre nourriture pour chien" (si vous me permettez d'emprunter une expression de ma langue maternelle).
      S'il y a un problème avec OpenCL, c'est mieux que nous l'ayons découvert au lieu de nos utilisateurs.

   Bref, je veux accélérer l'adoption d'OpenCL sur les systèmes d'exploitation libres.

   Voici l'autre raison plus subtil et plus pertinent à mes intérêts personnels comme une sorcière du graphisme. Pouvoir écrire les pilotes dans une langue de haut niveau aide le développement. Mesa a utilisé l'équivalent d'une langage d'assemblage pour les fonctionnalités complexes qui requièrent l'émulation. Bien que ça fonctionne, c'est lent et ça pose des problèmes pour la maintenance du pilote. OpenCL C résolut parfaitement ces problèmes. Les pilotes graphiques deviennent encore plus compliqués, car la croissance des spécifications ne cesse pas. OpenCL est l'arme qui nous permet de gérer cette complexité dans la guerre contre les pilotes propriétaires et les APIs pas standardisés.

   Ce point final n'est pas théorique. Les pilotes propriétaires utilisent déjà les langues de haut niveau pour leur tâches internes. Il faut que nous fassions le même. Je refuse de perdre notre avantage à cause d'une réticence à profiter des outils que nous avons déjà construits.

   Voilà le secret de mon progrès rapide sur les pilotes d'Asahi... Tous les pilotes libres peuvent l'imiter. Au moins, Intel l'a déjà fait, donc ne faisons pas honte à Intel. Plutôt, souhaitons que les autres pilotes libres suivent son exemple.

   (Et si vous avez besoin de faire honte, faite-la à moi.)