Thomas: merci, oui j'ai le même problème avec Darktable. A voir si je compile la dernière version de Mesa, et LLVM.
EdB: merci c'est bon a savoir.
Je doit participé, et de je devrais me servir d'un ordinateur avec une R9 290 avec Mesa(radeonSI), Clover, donc je devrais pouvoir te faire des retours.
Email envoyé également, c'est une super initiative, en plus il parrait que le projet Gimp manque de bras (et de cerveaux).
Vu que tu es dev Gimp tu pourra peu être me renseigner, quel sont les prérequis software/hardware pour travailler sur la parti OpenCL ?
Et surtout est ce que c'est possible avec les drivers opensource. Plutôt Radeonsi en ce qui me concerne, ou peut être beignet (en mode cpu only).
Je n'est pas de lien sous la main, mais des gens de chez AMD on participé à des implémentation OpenCL de certain traitement dans LibreOffice (calc) et dans Blender.
Gimp avec leur nouveau système de traitement d'image GEGL, devrais dans la prochaine version faire une utilisation intéressante d'OpenCL.
Et il doit surrement y avoir d'autres applications pour les utilisateurs classiques.
Posté par xoddark .
En réponse au journal GPUOpen.
Évalué à 0.
Dernière modification le 28 janvier 2016 à 19:08.
Je ne connais pas tout les détail de CUDA, mais comparer HSA a CUDA ne me semble pas très pertinent.
AMD a OpenCL qui serais un équivant de CUDA, et les performance GPGPU des cartes AMD sont reconnus depuis quelques temps.
La pile HSA c'est quand même l'étape suivante, ça doit améliorer le mélange de calcul CPU et GPU et facilité l'utilisation du GPU pour les développeurs.
AMD n'est surement pas altruistes et pas exempt de reproche, mais il me semble qu'il ont une politique beaucoup plus ouverte et respectueuse des utilisateurs.
Et une chose est sur ils sont à l'origine ou pousse de nombreuses évolutions de façon ouverte (Mantle qui a donné Direct3D 12 et Vulkan, HSA, HBM, Freesync, ).
Posté par xoddark .
En réponse au journal GPUOpen.
Évalué à 2.
Est ce que tu aurais des sources sur les outils Gameworks qui baisserais volontairement les performances sur AMD ?
Étant donnée les différences d'architecture, ça ne serai pas étonnais que certaine optimisation très poussé pour Nvidia soit contre productive sur AMD, mais ce n'est pas ce que je comprend dans le volontairement.
Posté par xoddark .
En réponse au journal GPUOpen.
Évalué à 10.
AMD essaye d'attirer de nouveau développer et utilisateur vers leur plateforme.
Et un des moyens c'est d'avoir un développement plus ouvert.
Ils ont aussi du se séparer de beaucoup d'employé, donc ils doivent manquer de monde pour développer les outils, libs, etc utile aux développeurs.
Passer ses outils en open source peut permettre d'augmenté le capital de la société au près des devs, et de leur permettre d'avoir des meilleurs outils que s'ils les développait seul.
En tout cas c'est une société qui fait beaucoup d'effort pour amélioré les choses (HSA, Freesync, Mantle/Vulkan), même si c'est en parti par contrainte (s'ils veulent survivre).
Donc j'espère que tout ses efforts porterons leurs fruits avant qu'ils soient mort ou revendu.
Hello, merci pour ce travail, et bonne chance pour la campagne.
Pour ce qui est de la version Sailfish OS, pas besoin d'une version native (dans un premier temps).
Par contre une version Android disponible sur le dépôt jolla du store Aptoide serais cool :)
Cool, tant qu'a faire autant présenté le maximum d'info.
L'idée pour moi était de parler plus des utilisations ou la bidouille est possible, à l'opposé des téléphones ou le bootloader est fermé par exemple.
Je ne pense pas qu'il y est besoin de lister toute les carte de dev. Wikipedia fait ça très bien. Par contre lister les mini ordinateur ARM orienté utilisateur final peu être sympa (Cubox, TBS matrix, etc).
Et ensuite la partie software, à la fois l'état de libritude/remonté upstream et les usages possible.
Je pense que c'est ce qui intéressera le plus les lecteurs de linuxfr :)
Ensuite si vous avez d'autres idées de contenu on rajoutera.
Effectivement ma liste est très restreinte, l'idée était de parler des plate-formes que je connais pas trop mal.
Mais je reconnais que mon titre est trompeur, je m'en excuse mais je n'en ai pas trouver de mieux.
Par contre si d'autre personnes sont intéressé pour participé, peu être qu'une dépêche pourrais être créé à partir de ce journal et des différents commentaires. Peu être en orientant un peu plus sur les utilisations possible et accessible sur ce genre de matériel.
Effectivement j'avais regarder pas mal leur carte a une époque.
Il me semble que la partie display des exynos à des drivers upstream dans le kernel, par contre la partie acceleration graphique (mali) n'en a pas.
Dommage que le projet lima ne soit plus actif.
Dsl pour la réponse tardive du coup.
J'aurais pu, mais changement de programme, je serais au travail.
Je pourrais peut être être sur IRC, mais je ne pourrais pas tester sur mes boards.
En tout merci pour la proposition, ça aurais été avec plaisir :)
Bonne idée, mais je ne pourrais pas venir à Paris.
Des personnes pourrais organiser ça à Lyon ?
Je suis utilisateur de Fedora sur mon portable, et j'ai 2 cartes ARM qui pourrais être testé (Wandboard et IFC6410).
Mais je ne connais pas les processus de tests de Fedora, donc je ne pourrais pas organiser/animer.
ça dépend des jeux.
C'est marqué dans la configuration requise quand c'est du Wine à priori (Les 2 Flatout par exemple).
La configuration requise est indiqué par plate-forme en bas de la description (je ne l'avais pas vu au départ).
Oui Gallium est une interface entre la gestion des API (OpenGL, OpenCL, etc) et les drivers spécifiques au matériel.
Parmit les différents drivers compatible Gallium il y en a un basé sur llvm qui s'exécute sur le CPU, mais il y a aussi les drivers r300g, r600g, si, nouveau, … qui sont implémentés pour utiliser gallium.
Pour en revenir à Southern Island il me semble que ça a pas mal avancé, que tout est en place, et que ça fonctionne à peu près. Sauf que tout n'est pas forcement la/actif dans les versions stable/inclue dans les distributions des composants (Kernel, Mesa, divers X.Org, glamors, …).
[^] # Re: Niveau technique à considérer.
Posté par xoddark . En réponse à la dépêche Formation OpenCL en contribuant à GIMP. Évalué à 1.
Thomas: merci, oui j'ai le même problème avec Darktable. A voir si je compile la dernière version de Mesa, et LLVM.
EdB: merci c'est bon a savoir.
Je doit participé, et de je devrais me servir d'un ordinateur avec une R9 290 avec Mesa(radeonSI), Clover, donc je devrais pouvoir te faire des retours.
[^] # Re: Niveau technique à considérer.
Posté par xoddark . En réponse à la dépêche Formation OpenCL en contribuant à GIMP. Évalué à 1.
Email envoyé également, c'est une super initiative, en plus il parrait que le projet Gimp manque de bras (et de cerveaux).
Vu que tu es dev Gimp tu pourra peu être me renseigner, quel sont les prérequis software/hardware pour travailler sur la parti OpenCL ?
Et surtout est ce que c'est possible avec les drivers opensource. Plutôt Radeonsi en ce qui me concerne, ou peut être beignet (en mode cpu only).
Merci
[^] # Re: OpenCL : quelles applications ?
Posté par xoddark . En réponse à la dépêche Les pilotes graphiques libres : rétrospective et vue sur l’avenir. Évalué à 4.
Je n'est pas de lien sous la main, mais des gens de chez AMD on participé à des implémentation OpenCL de certain traitement dans LibreOffice (calc) et dans Blender.
Gimp avec leur nouveau système de traitement d'image GEGL, devrais dans la prochaine version faire une utilisation intéressante d'OpenCL.
Et il doit surrement y avoir d'autres applications pour les utilisateurs classiques.
[^] # Re: Gameworks
Posté par xoddark . En réponse au journal GPUOpen. Évalué à 1.
Ok merci pour les liens.
J'avais entendu parler d'agissement pas très faire play de la part d'NVidia sans avoir de source.
Mais je savais pourquoi je voulais plutôt du AMD que du NVidia dans mes ordinateurs.
[^] # Re: Version rapide
Posté par xoddark . En réponse au journal GPUOpen. Évalué à 0. Dernière modification le 28 janvier 2016 à 19:08.
Je ne connais pas tout les détail de CUDA, mais comparer HSA a CUDA ne me semble pas très pertinent.
AMD a OpenCL qui serais un équivant de CUDA, et les performance GPGPU des cartes AMD sont reconnus depuis quelques temps.
La pile HSA c'est quand même l'étape suivante, ça doit améliorer le mélange de calcul CPU et GPU et facilité l'utilisation du GPU pour les développeurs.
AMD n'est surement pas altruistes et pas exempt de reproche, mais il me semble qu'il ont une politique beaucoup plus ouverte et respectueuse des utilisateurs.
Et une chose est sur ils sont à l'origine ou pousse de nombreuses évolutions de façon ouverte (Mantle qui a donné Direct3D 12 et Vulkan, HSA, HBM, Freesync, ).
[^] # Re: Gameworks
Posté par xoddark . En réponse au journal GPUOpen. Évalué à 2.
Est ce que tu aurais des sources sur les outils Gameworks qui baisserais volontairement les performances sur AMD ?
Étant donnée les différences d'architecture, ça ne serai pas étonnais que certaine optimisation très poussé pour Nvidia soit contre productive sur AMD, mais ce n'est pas ce que je comprend dans le volontairement.
# Version rapide
Posté par xoddark . En réponse au journal GPUOpen. Évalué à 10.
AMD essaye d'attirer de nouveau développer et utilisateur vers leur plateforme.
Et un des moyens c'est d'avoir un développement plus ouvert.
Ils ont aussi du se séparer de beaucoup d'employé, donc ils doivent manquer de monde pour développer les outils, libs, etc utile aux développeurs.
Passer ses outils en open source peut permettre d'augmenté le capital de la société au près des devs, et de leur permettre d'avoir des meilleurs outils que s'ils les développait seul.
En tout cas c'est une société qui fait beaucoup d'effort pour amélioré les choses (HSA, Freesync, Mantle/Vulkan), même si c'est en parti par contrainte (s'ils veulent survivre).
Donc j'espère que tout ses efforts porterons leurs fruits avant qu'ils soient mort ou revendu.
# Version Sailfish OS
Posté par xoddark . En réponse à la dépêche Libervia/Salut à Toi : campagne pour une version Android et de bureau. Évalué à 3.
Hello, merci pour ce travail, et bonne chance pour la campagne.
Pour ce qui est de la version Sailfish OS, pas besoin d'une version native (dans un premier temps).
Par contre une version Android disponible sur le dépôt jolla du store Aptoide serais cool :)
Bon courage.
[^] # Re: Liste relativement restreinte
Posté par xoddark . En réponse au journal ARM: Etat des lieu dans la communauté linux. Évalué à 1.
Cool, tant qu'a faire autant présenté le maximum d'info.
L'idée pour moi était de parler plus des utilisations ou la bidouille est possible, à l'opposé des téléphones ou le bootloader est fermé par exemple.
Je ne pense pas qu'il y est besoin de lister toute les carte de dev. Wikipedia fait ça très bien. Par contre lister les mini ordinateur ARM orienté utilisateur final peu être sympa (Cubox, TBS matrix, etc).
Et ensuite la partie software, à la fois l'état de libritude/remonté upstream et les usages possible.
Je pense que c'est ce qui intéressera le plus les lecteurs de linuxfr :)
Ensuite si vous avez d'autres idées de contenu on rajoutera.
[^] # Re: Liste relativement restreinte
Posté par xoddark . En réponse au journal ARM: Etat des lieu dans la communauté linux. Évalué à 2.
Ok, Je ne suis pas pressé, je préfère la qualité :)
J'essaierais de préparer une base de dépêche dans les jours à venir.
[^] # Re: Liste relativement restreinte
Posté par xoddark . En réponse au journal ARM: Etat des lieu dans la communauté linux. Évalué à 3.
Effectivement ma liste est très restreinte, l'idée était de parler des plate-formes que je connais pas trop mal.
Mais je reconnais que mon titre est trompeur, je m'en excuse mais je n'en ai pas trouver de mieux.
Par contre si d'autre personnes sont intéressé pour participé, peu être qu'une dépêche pourrais être créé à partir de ce journal et des différents commentaires. Peu être en orientant un peu plus sur les utilisations possible et accessible sur ce genre de matériel.
[^] # Re: les odroid de hardkernel ?
Posté par xoddark . En réponse au journal ARM: Etat des lieu dans la communauté linux. Évalué à 2.
Effectivement j'avais regarder pas mal leur carte a une époque.
Il me semble que la partie display des exynos à des drivers upstream dans le kernel, par contre la partie acceleration graphique (mali) n'en a pas.
Dommage que le projet lima ne soit plus actif.
[^] # Re: Même chose à Lyon ?
Posté par xoddark . En réponse à la dépêche Journée de test pour la Fedora 21 le 8 novembre 2014 à Paris. Évalué à 1.
Dsl pour la réponse tardive du coup.
J'aurais pu, mais changement de programme, je serais au travail.
Je pourrais peut être être sur IRC, mais je ne pourrais pas tester sur mes boards.
En tout merci pour la proposition, ça aurais été avec plaisir :)
# Même chose à Lyon ?
Posté par xoddark . En réponse à la dépêche Journée de test pour la Fedora 21 le 8 novembre 2014 à Paris. Évalué à 5.
Bonne idée, mais je ne pourrais pas venir à Paris.
Des personnes pourrais organiser ça à Lyon ?
Je suis utilisateur de Fedora sur mon portable, et j'ai 2 cartes ARM qui pourrais être testé (Wandboard et IFC6410).
Mais je ne connais pas les processus de tests de Fedora, donc je ne pourrais pas organiser/animer.
[^] # Re: C'est du natif ?
Posté par xoddark . En réponse au journal GOG débarque sous Linux. Évalué à 3.
ça dépend des jeux.
C'est marqué dans la configuration requise quand c'est du Wine à priori (Les 2 Flatout par exemple).
La configuration requise est indiqué par plate-forme en bas de la description (je ne l'avais pas vu au départ).
[^] # Re: Au passage
Posté par xoddark . En réponse au journal Pilotes ATI libres, voici venu le temps du Glamour. Évalué à 4.
Oui Gallium est une interface entre la gestion des API (OpenGL, OpenCL, etc) et les drivers spécifiques au matériel.
Parmit les différents drivers compatible Gallium il y en a un basé sur llvm qui s'exécute sur le CPU, mais il y a aussi les drivers r300g, r600g, si, nouveau, … qui sont implémentés pour utiliser gallium.
Pour en revenir à Southern Island il me semble que ça a pas mal avancé, que tout est en place, et que ça fonctionne à peu près. Sauf que tout n'est pas forcement la/actif dans les versions stable/inclue dans les distributions des composants (Kernel, Mesa, divers X.Org, glamors, …).