AlexTérieur a écrit 439 commentaires

En plus, ça casse les oreilles.

En fait, de ce que j'ai compris, ROCm ce n'est pas qu'un pilote ou une architecture/pilote, mais un ensemble d'outils tournant autour du traitement par GPU (classiquement OpenCL et en version > ou = à 2). Rien ne dit que par la suite Mesa n'intègrera pas l'ICD que propose ROCm, par contre je n'en sais rien des discussions.

Non, en fait le gros problème de ROCm est son support qui n'est pas "complet", par exemple, étant utilisateur Fedora, impossible d'utiliser sans bidouille les paquets RPM qui sont prévus pour CentOS/RHEL… Là avec Fedora 33, ça s'est amélioré même si ce n'est pas "officiel", il marche sans problème il faut juste changer manuellement le lien symbolique vers le bon pilote ICD. On ne touche absolument pas aux pilotes de la cartes graphiques, qui resteront ceux qu'on a installé. J'avais réussi à faire fonctionner OpenCL sur Fedora 31/32 au prix d'une grosse bidouille un peu limite (exploiter un dépôt RPM bidouillé pour être installable sous Fedora, c'était le propos de mon journal) mais là, on peut installer proprement ROCm et changer le lien symbolique, ça reste beaucoup moins "crade" comme manip.

Tout est expliqué dans le lien que j'ai donné dans le commentaire de l'autre journal : https://linuxreviews.org/Radeon_Open_Compute

Force est de constater que AMD a fait un choix sur le long terme, qui n'apparaissait pas gagnant sur le moment mais qu'aujourd'hui plus personne ne peut contester. Perso, c'est à chaque fois bonheur d'installer un nouvel OS sans me soucier de la question performance graphique… ça n'a pas été toujours le cas, bien évidemment.
Cela fait un moment que, bien qu'étant loin d'être un "gamer", j'aime jouer occasionnellement tout en restant sur Linux. Ça doit bien faire au moins 3 années où jamais je n'ai poussé un soupir "ah, et si ça marchait aussi bien que Windows"…
Le jeu qui m'a le plus stupéfait est Resident Evil 2 Remake. Il a fonctionné à la perfection, sur ma pauvre RX 580 (8 Go tout de même), options graphiques presque tout à fond, fluidité sans aucune chute de framerate. Le meilleur, c'est que j'aurai pu jouer en 4K si j'avais baissé quelques options graphiques (véridique).

Et sinon, pour le support OpenCL, j'ai répondu à un journal, une réponse qui est restée confidentielle, parce que j'avais fait un journal auparavant traitant de la difficulté d'avoir OpenCL sur AMD en 100% libre, mais comme je l'ai dit dans la réponse, les choses semblent avoir changer.

Bon bin toujours le bug… décidément, drôle de bug.

Bon bin depuis la toute dernière MàJ Fedora je n'ai plus ce problème. Voilà un bug dont l'évolution m'a échappé. Heureusement l'essentiel est que cela fonctionne.

Bien joué, ça doit être ça, merci. Je n'avais pas fait le rapprochement avec Waylan et WebRender.

Ah je n'avais pas compris. Il y a des infos dessus ? Rapport de bogue ? Je n'arrive pas à trouver.

Non, de ça :

Pour les grands et les petits.

Il me semble que "Servo" c'était un peu le truc "fourre-tout" de Mozilla concernant Firefox ? Une sorte de gros "bac-à-sable" et de patchwork d'idées qui seraient ou non intégrés par la suite dans Firefox ? Et que d'ailleurs "Servo" a engendré WebRender qui est aujourd'hui intégré à Firefox ? Quelqu'un peut éclaircir SVP…
Bref, que "Servo" n'a jamais été "le futur" de Mozilla…

Depuis la mise à jour vers la 83, j'ai plusieurs extensions qui affichent tout "blanc", impossible donc de les utiliser. Cela l'a fait pour uBlock Origin, uMatrix et Privacy Badger. J'ai du désinstaller uMatrix d'ailleurs. Je n'arrive pas à voir s'il y a un rapport de bogue dessus. Quelqu'un a des infos ?

C'est quoi ? La nouvelle version majeure basée sur GTK4 ?

C'est clair. Un attentat qui ferait plus de victimes que le Bataclan et qui est revendiqué du racialisme blanc, j'ai vraiment du mal à croire que ça serait passé sous silence… Ne serait-ce que même en dehors des grands médias.

Exemple 1 : le support d'OpenCL avec le développement de Clover a été arrêté en faveur de ROCm. Si ROCm a des avantages, ce n'est pas disponible out-of-the-box, ça ne s'intègre pas forcément bien dans les distributions linux, et ça ne supporte que les GPU et carte mère avec des features récente mais pas forcément les dernier GPU.

J'avais posté un journal où j'expliquais les difficultés d'avoir l'accélération OpenCL sur Fedora, en plus on a Clover et ROCm ne marchait pas ; on dirait que ça a changé depuis que je suis passé à Fedora 33, j'ai réussi à installer ROCm et à l'exploiter (testé sous Darktable).

Pour plus d'info notamment sur l'installation et sur le matériel compatible, suivre ce lien.

As-tu regardé chez les grands constructeurs, car certains proposent de préinstaller du Linux.
Qu'est-ce qui a fait pencher la balance ?

C'est peut-être donné à l'orientation du Snap, mais à la base ce ne sont pas des stores (je me répète…) dans leur principe de fonctionnement… Ca c'est Canonical qui a voulu reprendre les codes Android et maintenant Windows, en créant une centralisation des Snaps tel un "store" en croyant que cela les aiderait à se faire une pub… vu les critiques sur Snap, apparemment, c'est râpé…

Snap et Flatpak des magasins d'applications ? Non !!! Ce sont avant tout des méthodes d'empaquetage des applications avec les dépendances compilées en "statique", ou en environnement sandboxé. Pas des stores.

Qu'est ce qui te fait croire que ces "gris" n'ont pas déjà choisi ? Ou alors les "gris" savent violer les inégalités de Bell :)

Je trouve dommage (non pas pour moi mais en général je parle) qu'un logiciel ayant un large spectre d'utilisateurs comme le sont les logiciels bureautiques n'ont pas implémenté une fonction permettant d'exporter en lot de PDF, et donc nécessitant de passer par la ligne de commande.

En fait, pour chaque périphérique nécessitant d'exploiter la colorimétrie, il y a possibilité d'appliquer un profil de couleur. Le scanner (tout comme l'imprimante) n'y échappe pas.
Il existe des solutions : des entreprises fournissent des images imprimées dont la colorimétrie est parfaitement maitrisée, et il suffit de les scanner et de lancer un logiciel ou bien de corriger à la main les différences entre l'image scannée et l'image théorique. Mais il faut bien s'en douter que ce n'est pas gratuit, en plus d'être un peu "overkill".
Le plus simple et le moins cher, je pense, serait de partir d'un écran parfaitement calibré, puis de scanner une image, et ensuite de tâter les paramètres jusqu'à avoir la même perception chromatique sur l'image physique et l'image affichée.
Après, la correction colorimétrique d'un scanner n'est à mon sens pas essentiel, car quand on scanne, on est censé passer sur un logiciel de retouche d'image, et donc qu'on peut toujours rattraper un scanner "défectueux" après coup. C'est impossible pour un écran ou une imprimante, car il n'existe pas d'intermédiaire entre l’œil (l’observateur) et le support (l'image affichée ou imprimée).

C'est une idée, mais pas forcément bonne… en effet, chaque capteur aura sa propre dérive chromatique…
Personnellement, la seule chose est que je ne sais pas comment garantir la régularité chromatique pour n'importe quel capteur… je crois qu'il y a d'ailleurs peu de documentations là dessus. On est donc obligé de faire confiance aux constructeurs de sondes…

Oui, les joies de la bidouille à l'époque à décortiquer les trames NMEA…
Il n'empêche, le milieu open source maîtrise assez bien le domaine du positionnement par satellite, il y a quelques projets sympa comme celui-ci : https://fortebit.tech/polaris/

C'est pour l'amour du RISC.

Encore et une fois, il faut se poser la question de l'usage…
Un GPS aujourd'hui, même sans Galileo, c'est 98% des usages grands publics couverts, avec des précisions à 3-4 m 99% du temps…
Si c'est pour un usage plus précis, décimétrique voire centimétrique, les solutions "correction temps réel" (RTK) avec réseau d'antennes satellites (Orphéon, Teria etc.) est la plus simple,; la plus rapide mais les prix s'envolent allègrement.