News: 2023-06-09T04_30_00Z

  ARM Give a man a fire and he's warm for a day, but set fire to him and he's warm for the rest of his life (Terry Pratchett, Jingo)

Asahi Linux : prise en charge d’OpenGL 3.1 avant Vulkan

(2023/06/09)


Asahi Linux : prise en charge d’OpenGL 3.1 avant Vulkan

vendredi 9 juin 2023

Si vous utilisez Linux sur un Mac M1/M2, bonne nouvelle : une mise à jour d’Asahi Linux introduit une nouveauté au niveau des pilotes graphiques. Ils passent à OpenGL 3.1, avec la prise en charge d’OpenGL ES 3.0. Quel intérêt ?

Nous [1]vous en avons déjà parlé sur Toolinux. [2]Asahi Linux est une distribution GNU/Linux optimisée pour les puces Apple Silicon (M1, M2) qui équipent désormais la plupart des ordinateurs et tablettes professionnelles de l’entreprise. Ses développeurs viennent d’annnoncer une très importante nouveauté dans la perspective du support des GPU Apple avec la prise en charge d’OpenGL 3.1 .

Les pilotes pour les puces Apple sont [3]open source . Le travail, lui, est important, car les GPU Apple sont très différents de ce que l’on trouve généralement dans les puces Intel classiques (y compris sur les Mac avec puces Intel).

Si cette annonce représente une amélioration, elle peut étonner voire décevoir face à Mesa et à Vulkan. Les développeurs tiennent toutefois à rassurer les utilisateurs : l’objectif final est [4]un pilote Vulkan . « Nous en sommes encore loin, mais les exigences de base de Vulkan 1.0 sont parallèles à celles d’OpenGL ES 3.1, de sorte que notre travail s’applique à Vulkan. » Le bond en avant sera alors beaucoup plus notable, notamment pour les jeux vidéo.

[5]



[1] https://www.toolinux.com/?linux-sur-l-architecture-m2-d-apple-ou-en-est-on

[2] https://asahilinux.org/

[3] https://asahilinux.org/2023/06/opengl-3-1-on-asahi-linux/

[4] https://github.com/ella-0

[5] https://www.toolinux.com/?asahi-linux-prise-en-charge-d-opengl-3-1-avant-vulkan#forum



It is a very humbling experience to make a multimillion-dollar mistake, but
it is also very memorable. I vividly recall the night we decided how to
organize the actual writing of external specifications for OS/360. The
manager of architecture, the manager of control program implementation, and
I were threshing out the plan, schedule, and division of responsibilities.
The architecture manager had 10 good men. He asserted that they
could write the specifications and do it right. It would take ten months,
three more than the schedule allowed.
The control program manager had 150 men. He asserted that they
could prepare the specifications, with the architecture team coordinating;
it would be well-done and practical, and he could do it on schedule.
Furthermore, if the architecture team did it, his 150 men would sit twiddling
their thumbs for ten months.
To this the architecture manager responded that if I gave the control
program team the responsibility, the result would not in fact be on time,
but would also be three months late, and of much lower quality. I did, and
it was. He was right on both counts. Moreover, the lack of conceptual
integrity made the system far more costly to build and change, and I would
estimate that it added a year to debugging time.
-- Frederick Brooks Jr., "The Mythical Man Month"