Bonjour, je suis utilisateur d'un domaine gandi (maxzor.eu) et je me sers intensément de ma boîte mail liée. Je télécharge en local sur thunderbird les mails. Est-ce que demain elle ne fonctionnera plus du tout ?
Oui, niveau intégration, documentation et lobbying Nvidia n'a pas son pareil.
A l'époque où NVidia a lancé à pleine vapeur CUDA, AMD commençait à peine la R&D HSA, avec un compilateur maison, une représentation intermédiaire HSAIL maison, une cible de compilation universelle GPU FPGA DSP… Ca n'a pas marché, je ne sais pas pourquoi, et AMD s'est depuis rabattu sur de la compilation "GPU classique": avec un backend LLVM qui cible les GPUs uniquement - backend complètement ouvert.
Donc AMD a dix ans de retard sur le "compute"/GPGPU. Et pas de super moyens investis pour mettre ROCm à disposition du grand public et toujours une énorme focalisation sur les superordinateurs, ANL, LNLL, El Capitan/Frontier…
Puis il y a une scission entre deux pilotes noyaux au sein du même module amdgpu, qui persiste encore aujourd'hui, ce qui ne facilite pas les choses.
Ce que j'ai chiné comme info ces dernières semaines d'investigation^
J'aide Debian à empaqueter ROCm. J'ai poussé sur le dépôt gitlab Debian de l'équipe une première mouture de l'implémentation OpenCL 2.2 ROCm (avec son ICD): clinfo ne fonctionne pas et un connaisseur de cette API serait le bienvenu!
Il y a bien une équipe dédiée chez Debian, mais pour l'instant ils n'ont pas répondu.
Question qui a l'air de troll mais qui n'en est pas: pourquoi tenez-vous à OpenCL? N'est-il pas plus agréable de programmer en C++ 17 avec HIP(~CUDA)? Oui je ne connais pas grand chose à la programmation GPU, je veux juste que Blender + HIP fonctionne ':)
Personnellement, je suis intéressé par le GSoC, mais plutôt pour l'interop HIP/Mesa Vulkan (RADV) qui est ce que le moteur de rendu Cycles de Blender utilise.
D'accord que le support est beaucoup trop court pour ROCm.
Je me pose la question de savoir si c'est légitime de m'inscrire au GSoC 2022.
La collection d'APIs ROCm d'AMD permet de faire de l'accélération GPU pour diverses applications.
Pour l'instant elle ne supporte pas l'interop avec les applications graphiques, c'est-à-dire que la partie API GPGPU style OpenCL, et la partie rendu type OpenGL et Vulkan, ne communiquent pas facilement, au grand dam de Blender et son moteur de rendu Cycles par example.
J'ai contribué avec l'équipe dédiée chez Debian à empaqueter cette pile logicielle ROCm, on est pas [trop trop] loin d'avoir terminé. Je suis aussi en train d'écrie l'article wikipédia sus-cité.
On m'a dit récemment que le focus chez AMD est à l'interop avec ses drivers propriétaires (côté windows uniquement?) qui pourrait voir le jour avec la publication imminente de ROC 5.1. La contribution et le sujet GSoC que j'envisage seraient donc de développer l'interop entre ROCm (HIP/OpenCL) avec Mesa, la pile graphique libre (OpenGL, Vulkan 1.3). C'est un sujet carrefour donc potentiellement compliqué d'établir clairement qui est sponsor, entre AMD, Mesa, un projet comme Blender/DarkTable…
J'ai acheté un kit de dev Librem5 en 2017.
Ils ont fait un gros boulot notamment au niveau firmware.
Je ne pleure pas, c'est le seul SoC acceptable de mon point de vue.
Je l'achèterai un jour.
Renseigne-toi. Le parseur en question est un immonde usine à gaz, tous ceux avec qui j'ai échangé ayant approché de près ou de loin le langage de balisage de mediawiki disent la même chose : c'est une erreur de jeunesse qui colle au projet comme le bout de sparadrap du capitaine Haddock et embête beaucoup de monde.
L'interopérabilité du contenu, et c'est un comble pour une encyclopédie, n'est pas là. C'est triste.
Et j'y ai passé du temps dans les dumps mariadb wikipedia.
Il y a des thèses pour parser le wikitext, tellement le besoin est là et la solution absente.
Wikidata est très bien, mais ça n'est pas le sujet.
Comment faire face à ces tas de prose de façon un peu construite?
Comment brancher des réseaux neuronaux pour améliorer le niveau des articles?
Wikitext est un défaut de conception primordial qui me paraît malheureusement irrattrapable…
Wikijs a pris le chemin sain markdown / html / un standard en WYSIWYG.
Voilà, le plus gros des communs de la connaissance humaine est dans un format imbitable.
Où en sont la fondation ou mediawiki pour revoir ça?
Possible de miner facilement depuis les archives le fond sans la forme?
Si rien, urgence à format moins merdique (je pèse mes mots, il y a deux ans il n'y avait pas de BNF ni de parseur un tant soit peu standard), ou, plus radicalement, alternative à Wikimedia, qui commence à dater sérieusement avec son php comme son mariadb.
C'était un super projet il y a vingt ans, il a pris un gros coup de vieux.
J'ai creusé profond chez le sexy wikijs (node + postgres), mais c'est pas la même ambition en passage à l'échelle ni en périmètre fonctionnel.
Posté par Maxzor .
En réponse à la dépêche Sortie d’Odoo 14.
Évalué à 1.
Dernière modification le 06 octobre 2020 à 09:23.
Freemium
Avec gros accent sur les pépètes plus que sur la doc, mon micro-feedback d'un parcours et d'une install superficiels d'il y a trois mois.
Fin c'est pas pire que Qt ou NGinx ces derniers temps
Posté par Maxzor .
En réponse à la dépêche Annonce de Perl 7.
Évalué à 0.
Dernière modification le 20 août 2020 à 14:53.
Je n'ai jamais fait de perl, je fais du shell, du sed, un peu d'awk, du python.
lol, svp pas la programmation avec exceptions!
Le non utf8 en interne est un gros problème je trouve.
Ce qui manque aujourd'hui dans ma compréhension actuelle est une bibliothèque de traitement utf8 décente niveau performance et fonctionnalité.
Ni perl, ni icu - ce dernier est issue du monde sun et java, utf16 en interne - ne paraissent remplir ce rôle…
Pour faire des volumes 'non tout bêtes' avec FreeCad c'est pas évident, je me rappelle avoir passé des heures à essayer de créer des NURBS, des splines, ou même bêtement en 2D un polynôme d'interpolation… et c'est pas la joie.
NB Je n'ai pas encore imprimé de pièce avec Blender alors qu'avec FreeCAD des tonnes, j'ai juste lu que c'était possible.
Même si effectivement blender ne gère pas les contraintes mécaniques, son ergonomie plus poussée et ses fonctionnalités me le feront je pense souvent préférer à FreeCAD :
- Catmull-Clark subdivision modifier
- Le plugin 'Cell fracture' (cf. lava monster)
- Extract, dissolve and intersect arrive avec la 2.9
Pour moi c'était un choc, passer d'une création de volumes uniquement par primitives (cubes, sphères…) + opération booléennes + extrusion, à ça … sans compter la sculpture, les loopcuts et j'en passe!
Sans compter le super plugin Blender vers Unreal Engine 4 : Mannequin-Tools. Le cinéma est en train de remplacer les fonds verts par des écrans led avec Blender/UnrealEngine.
Si vous n'avez pas encore vu le teaser UE5 : https://www.youtube.com/watch?v=qC5KtatMcUw
Moins en rapport avec Blender et la 3D polygones, une découverte d'hier, un moteur de physique sur voxels : Teardown!
Je me suis enfin mis à Blender pendant le confinement et j'ai l'impression de ne pas être le seul :)
Surtout intéressé par la modélisation pour de l'impression 3D, je n'avais jamais utilisé que FreeCAD qui est libre aussi et beaucoup plus orienté dessin industriel.
Sur Youtube (…) hors le tuto donut de Blender Guru, je suis tombé sur une super série de Imphenzia, je mets en lien notamment le dragon et le monstre de lave : modélisation 'low-poly', rigging et animation en 10 minutes, ça dépote!
# Kezako
Posté par Maxzor . En réponse au journal Gandi mail - dernier rappel - et synchro des contacts et calendriers. Évalué à 1.
Bonjour, je suis utilisateur d'un domaine gandi (maxzor.eu) et je me sers intensément de ma boîte mail liée. Je télécharge en local sur thunderbird les mails. Est-ce que demain elle ne fonctionnera plus du tout ?
[^] # Re: OpenCL, portabilité et performance en général
Posté par Maxzor . En réponse à la dépêche OpenCL sous Linux : l’état des pilotes AMD est désormais pire que ce qu’il était à l’époque de fglrx. Évalué à 2.
oui! mais la route est longue…
https://www.reddit.com/r/Amd/comments/rd7mmi/heres_something_you_dont_see_every_day_pytorch/
[^] # Re: Sur Fedora
Posté par Maxzor . En réponse à la dépêche OpenCL sous Linux : l’état des pilotes AMD est désormais pire que ce qu’il était à l’époque de fglrx. Évalué à 2.
Jeremy Newton est en train d'empaqueter ROCm pour Fedora.
[^] # Re: Pou ceux qui aiment les langages de haut niveau ...
Posté par Maxzor . En réponse à la dépêche OpenCL sous Linux : l’état des pilotes AMD est désormais pire que ce qu’il était à l’époque de fglrx. Évalué à 2.
C'est clair que Rapids c'est quelque chose!
Il y a un back-end ROCm?!
[^] # Re: OpenCL, portabilité et performance en général
Posté par Maxzor . En réponse à la dépêche OpenCL sous Linux : l’état des pilotes AMD est désormais pire que ce qu’il était à l’époque de fglrx. Évalué à 5.
Oui, niveau intégration, documentation et lobbying Nvidia n'a pas son pareil.
A l'époque où NVidia a lancé à pleine vapeur CUDA, AMD commençait à peine la R&D HSA, avec un compilateur maison, une représentation intermédiaire HSAIL maison, une cible de compilation universelle GPU FPGA DSP… Ca n'a pas marché, je ne sais pas pourquoi, et AMD s'est depuis rabattu sur de la compilation "GPU classique": avec un backend LLVM qui cible les GPUs uniquement - backend complètement ouvert.
Donc AMD a dix ans de retard sur le "compute"/GPGPU. Et pas de super moyens investis pour mettre ROCm à disposition du grand public et toujours une énorme focalisation sur les superordinateurs, ANL, LNLL, El Capitan/Frontier…
Puis il y a une scission entre deux pilotes noyaux au sein du même module amdgpu, qui persiste encore aujourd'hui, ce qui ne facilite pas les choses.
Ce que j'ai chiné comme info ces dernières semaines d'investigation^
[^] # Re: OpenCL, portabilité et performance en général
Posté par Maxzor . En réponse à la dépêche OpenCL sous Linux : l’état des pilotes AMD est désormais pire que ce qu’il était à l’époque de fglrx. Évalué à 2. Dernière modification le 01 février 2022 à 20:32.
Ca c'est parce que tu sous-estimes le travail sur le backend llvm amdgpu kappa
P.S. je fais mon intéressant, en vérité j'en sais rien, sauf que tout le monde m'en dit des merveilles.
# OpenCL? ROCm?
Posté par Maxzor . En réponse à la dépêche OpenCL sous Linux : l’état des pilotes AMD est désormais pire que ce qu’il était à l’époque de fglrx. Évalué à 7. Dernière modification le 01 février 2022 à 13:49.
J'aide Debian à empaqueter ROCm. J'ai poussé sur le dépôt gitlab Debian de l'équipe une première mouture de l'implémentation OpenCL 2.2 ROCm (avec son ICD): clinfo ne fonctionne pas et un connaisseur de cette API serait le bienvenu!
Il y a bien une équipe dédiée chez Debian, mais pour l'instant ils n'ont pas répondu.
Question qui a l'air de troll mais qui n'en est pas: pourquoi tenez-vous à OpenCL? N'est-il pas plus agréable de programmer en C++ 17 avec HIP(~CUDA)? Oui je ne connais pas grand chose à la programmation GPU, je veux juste que Blender + HIP fonctionne ':)
Personnellement, je suis intéressé par le GSoC, mais plutôt pour l'interop HIP/Mesa Vulkan (RADV) qui est ce que le moteur de rendu Cycles de Blender utilise.
D'accord que le support est beaucoup trop court pour ROCm.
[^] # Re: ROCm - HIP - OpenCL - Mesa - OpenGL - Vulkan - Blender
Posté par Maxzor . En réponse à la dépêche Ouverture de l'appel à projet pour le Google Summer of Code. Évalué à 1.
Si le besoin existe déjà, ce qui n'est pas du tout clair vu la communication d'AMD…
# ROCm - HIP - OpenCL - Mesa - OpenGL - Vulkan - Blender
Posté par Maxzor . En réponse à la dépêche Ouverture de l'appel à projet pour le Google Summer of Code. Évalué à 3. Dernière modification le 28 janvier 2022 à 03:45.
Je me pose la question de savoir si c'est légitime de m'inscrire au GSoC 2022.
La collection d'APIs ROCm d'AMD permet de faire de l'accélération GPU pour diverses applications.
Pour l'instant elle ne supporte pas l'interop avec les applications graphiques, c'est-à-dire que la partie API GPGPU style OpenCL, et la partie rendu type OpenGL et Vulkan, ne communiquent pas facilement, au grand dam de Blender et son moteur de rendu Cycles par example.
J'ai contribué avec l'équipe dédiée chez Debian à empaqueter cette pile logicielle ROCm, on est pas [trop trop] loin d'avoir terminé. Je suis aussi en train d'écrie l'article wikipédia sus-cité.
On m'a dit récemment que le focus chez AMD est à l'interop avec ses drivers propriétaires (côté windows uniquement?) qui pourrait voir le jour avec la publication imminente de ROC 5.1. La contribution et le sujet GSoC que j'envisage seraient donc de développer l'interop entre ROCm (HIP/OpenCL) avec Mesa, la pile graphique libre (OpenGL, Vulkan 1.3). C'est un sujet carrefour donc potentiellement compliqué d'établir clairement qui est sponsor, entre AMD, Mesa, un projet comme Blender/DarkTable…
# Très cool
Posté par Maxzor . En réponse à la dépêche Compter automatiquement les mots prononcés sur les chaînes d'information continue. Évalué à 0.
La question qui me turlupine au vu des stats sur les sujets, c'est: CNews est devenu réac… mais de quoi parle BFMTV?
[^] # Re: Répétez la question s'il vous plaît
Posté par Maxzor . En réponse au sondage La politique sur LinuxFr.org. Évalué à 5.
En voilà un bon sondage qu'il est bien!
[^] # Re: et le purism????
Posté par Maxzor . En réponse à la dépêche Quel téléphone (plus ou moins) libre en 2021 ?. Évalué à 2. Dernière modification le 10 juin 2021 à 18:57.
J'ai acheté un kit de dev Librem5 en 2017.
Ils ont fait un gros boulot notamment au niveau firmware.
Je ne pleure pas, c'est le seul SoC acceptable de mon point de vue.
Je l'achèterai un jour.
[^] # Re: Wikitext arrrrghhhhhhhh
Posté par Maxzor . En réponse à la dépêche Wikipédia : vingt ans déjà !. Évalué à 0. Dernière modification le 05 février 2021 à 20:54.
Renseigne-toi. Le parseur en question est un immonde usine à gaz, tous ceux avec qui j'ai échangé ayant approché de près ou de loin le langage de balisage de mediawiki disent la même chose : c'est une erreur de jeunesse qui colle au projet comme le bout de sparadrap du capitaine Haddock et embête beaucoup de monde.
L'interopérabilité du contenu, et c'est un comble pour une encyclopédie, n'est pas là. C'est triste.
Et j'y ai passé du temps dans les dumps mariadb wikipedia.
Il y a des thèses pour parser le wikitext, tellement le besoin est là et la solution absente.
[^] # Re: Wikitext arrrrghhhhhhhh
Posté par Maxzor . En réponse à la dépêche Wikipédia : vingt ans déjà !. Évalué à 1.
Wikitext n'est pas parsable ou très mal, alors que le markdown très bien…
[^] # Re: Wikitext arrrrghhhhhhhh
Posté par Maxzor . En réponse à la dépêche Wikipédia : vingt ans déjà !. Évalué à -1. Dernière modification le 04 février 2021 à 18:32.
Wikidata est très bien, mais ça n'est pas le sujet.
Comment faire face à ces tas de prose de façon un peu construite?
Comment brancher des réseaux neuronaux pour améliorer le niveau des articles?
Wikitext est un défaut de conception primordial qui me paraît malheureusement irrattrapable…
Wikijs a pris le chemin sain markdown / html / un standard en WYSIWYG.
# Wikitext arrrrghhhhhhhh
Posté par Maxzor . En réponse à la dépêche Wikipédia : vingt ans déjà !. Évalué à -3. Dernière modification le 04 février 2021 à 18:22.
Voilà, le plus gros des communs de la connaissance humaine est dans un format imbitable.
Où en sont la fondation ou mediawiki pour revoir ça?
Possible de miner facilement depuis les archives le fond sans la forme?
Si rien, urgence à format moins merdique (je pèse mes mots, il y a deux ans il n'y avait pas de BNF ni de parseur un tant soit peu standard), ou, plus radicalement, alternative à Wikimedia, qui commence à dater sérieusement avec son php comme son mariadb.
C'était un super projet il y a vingt ans, il a pris un gros coup de vieux.
J'ai creusé profond chez le sexy wikijs (node + postgres), mais c'est pas la même ambition en passage à l'échelle ni en périmètre fonctionnel.
[^] # Re: Test Odoo
Posté par Maxzor . En réponse à la dépêche Sortie d’Odoo 14. Évalué à 1. Dernière modification le 06 octobre 2020 à 09:23.
Freemium
Avec gros accent sur les pépètes plus que sur la doc, mon micro-feedback d'un parcours et d'une install superficiels d'il y a trois mois.
Fin c'est pas pire que Qt ou NGinx ces derniers temps
# C'est pas pour casser l'ambiance
Posté par Maxzor . En réponse à la dépêche Java 15 est sorti. Évalué à -10.
mais qu'est ce que ce détritut de langage/écosystème a à faire avec une revue libriste?
# try-catch et pas d'utf8 interne
Posté par Maxzor . En réponse à la dépêche Annonce de Perl 7. Évalué à 0. Dernière modification le 20 août 2020 à 14:53.
Je n'ai jamais fait de perl, je fais du shell, du sed, un peu d'awk, du python.
lol, svp pas la programmation avec exceptions!
Le non utf8 en interne est un gros problème je trouve.
Ce qui manque aujourd'hui dans ma compréhension actuelle est une bibliothèque de traitement utf8 décente niveau performance et fonctionnalité.
Ni perl, ni icu - ce dernier est issue du monde sun et java, utf16 en interne - ne paraissent remplir ce rôle…
# Joli
Posté par Maxzor . En réponse à la dépêche 0 A.D : Empires Ascendant, rapport de développement septembre 2019 - mai 2020. Évalué à 4.
Bonjour,
Je ne connaissais qu'openage qui est moins avançé et uniquement un clone d'AoE2.
Joli projet bravo.
Vous pourriez mentionner sur le site que 0ad est empaqueté, au moins sur apt!
[^] # Re: Merci !
Posté par Maxzor . En réponse à la dépêche Meilleures contributions LinuxFr.org : les primées de mai 2020. Évalué à 4.
J'avais fait un article sur pgmodeler et postgres et j'ai pris le livre blender aussi :), il est pas mal!
[^] # Re: Waow
Posté par Maxzor . En réponse à la dépêche Blender 2.8x : la consécration. Évalué à 2.
Pour faire des volumes 'non tout bêtes' avec FreeCad c'est pas évident, je me rappelle avoir passé des heures à essayer de créer des NURBS, des splines, ou même bêtement en 2D un polynôme d'interpolation… et c'est pas la joie.
[^] # Re: Waow
Posté par Maxzor . En réponse à la dépêche Blender 2.8x : la consécration. Évalué à 5. Dernière modification le 19 mai 2020 à 13:36.
NB Je n'ai pas encore imprimé de pièce avec Blender alors qu'avec FreeCAD des tonnes, j'ai juste lu que c'était possible.
Même si effectivement blender ne gère pas les contraintes mécaniques, son ergonomie plus poussée et ses fonctionnalités me le feront je pense souvent préférer à FreeCAD :
- Catmull-Clark subdivision modifier
- Le plugin 'Cell fracture' (cf. lava monster)
- Extract, dissolve and intersect arrive avec la 2.9
Pour moi c'était un choc, passer d'une création de volumes uniquement par primitives (cubes, sphères…) + opération booléennes + extrusion, à ça … sans compter la sculpture, les loopcuts et j'en passe!
[^] # Re: Waow
Posté par Maxzor . En réponse à la dépêche Blender 2.8x : la consécration. Évalué à 8.
Sans compter le super plugin Blender vers Unreal Engine 4 : Mannequin-Tools. Le cinéma est en train de remplacer les fonds verts par des écrans led avec Blender/UnrealEngine.
Si vous n'avez pas encore vu le teaser UE5 : https://www.youtube.com/watch?v=qC5KtatMcUw
Moins en rapport avec Blender et la 3D polygones, une découverte d'hier, un moteur de physique sur voxels : Teardown!
# Waow
Posté par Maxzor . En réponse à la dépêche Blender 2.8x : la consécration. Évalué à 9. Dernière modification le 18 mai 2020 à 16:10.
Je me suis enfin mis à Blender pendant le confinement et j'ai l'impression de ne pas être le seul :)
Surtout intéressé par la modélisation pour de l'impression 3D, je n'avais jamais utilisé que FreeCAD qui est libre aussi et beaucoup plus orienté dessin industriel.
Sur Youtube (…) hors le tuto donut de Blender Guru, je suis tombé sur une super série de Imphenzia, je mets en lien notamment le dragon et le monstre de lave : modélisation 'low-poly', rigging et animation en 10 minutes, ça dépote!