Alors qu'EXA vient à peine de détroner XAA (l'infrastructure d'accélération 2D de XFree86 repris dans Xorg pour être ensuite viré par EXA) que UXA pointe maintenant le bout de son nez.
Pourquoi vous allez me dire ? Tout simplement parce que lors de l'adaptation de EXA à GEM [1] [2], Keith Packard n'a pas voulu modifier EXA pour le faire fonctionner avec GEM (ça aurait encore tout cassé) mais plutôt séparer les 2 travaux en dupliquant EXA ailleurs pour ensuite supprimer/adapter le code là où il y avait besoin. Le bébé fait 5000 lignes là où EXA fait environ 7500 lignes et Keith a donc décidé de l'appelé UXA (UMA Acceleration Architecture. Et UMA ? Mystère ...).
Pour les cancres qui n'auraient pas suivi, EXA sert à de l'accélération 2D sous Xorg et GEM sert dans la gestion de la mémoire de la carte graphique lors de l'accélération 3D. L'idée à la base de tout ceci étant la généralisation de GEM pour simplifier et réduire le code et accessoirement le rendre plus performant et également plus sûr.
Après l'intégration de la gestion du mode de la carte graphique dans le kernel ainsi que l'apparation prochaine de GEM dans le kernel, on ne peut que se réjouir de ces changements qui laisse entrevoir un avenir radieux pour l'accélération graphique sous Linux. Imaginez plutôt :
- plus de serveur tournant avec les droits root
- une vraie accélération 2D efficace
- une accélération 3D opensource fonctionnelle
- plus de changement de mode entre entre les consoles virtuelles et le serveur X
Bref que du bonheur.
[1] UMA Acceleration Architecture : http://keithp.com/blogs/UMA_Acceleration_Architecture/
[2] GEM Graphics Execution Manager : http://www.phoronix.com/scan.php?page=news_item&px=NjQ3Ng
Journal Ca fuse chez Xorg
6
août
2008
# XAA et 7.3
Posté par Lol Zimmerli (site web personnel, Mastodon) . Évalué à 3.
Option "AccelMethod" "XAA"À mon fichier /etc/X11/xorg.conf car sans X était devenu très, très, très lent. Quand ça passera à UXA c'en sera définitivement fini du mouvement?!
La gelée de coings est une chose à ne pas avaler de travers.
[^] # Re: XAA et 7.3
Posté par dguihal . Évalué à 5.
J'ai modifié quelques parametres :
Option "AccelMethod" "EXA"
Option "ExaNoComposite" "false"
Option "MigrationHeuristic" "greedy"
Et ca va beaucoup mieux.
[^] # Re: XAA et 7.3
Posté par Guillaume T . Évalué à 1.
C'était toujours plus lent.
Je sens ici revenir bientôt l'impondérable xrender vs imlib2 du respectable développeur d'Enlightenment, Rasterman...
Rendu software, rendu hardware, lourd débat. Seconde solution moins performante mais plus portable ?
J'ai par ailleurs eu oui dire d'un travail sur l'optimisation du temps de démarrage Xorg :
- plus de serveur tournant avec les droits root
- plus de changement de mode entre entre les consoles virtuelles et le serveur X
Il semble qu'il s'agissait de ce fameux GEM
[^] # Re: XAA et 7.3
Posté par _PhiX_ . Évalué à 2.
« J'ai par ailleurs ouï dire qu'un travail sur l'optimisation du temps de démarrage de Xorg apporterait les avantages suivants : »
[^] # Re: XAA et 7.3
Posté par Guillaume T . Évalué à -5.
Oui, mais non
Je suis allergique aux smileys.
L'orthographe française n'a qu'à mieux se tenir
[^] # Re: XAA et 7.3
Posté par Jean Roc Morreale . Évalué à 1.
[^] # Re: XAA et 7.3
Posté par Gyro Gearllose . Évalué à 7.
Je réponds au commentaire, parce que j'ignorais totalement ces options pour chipset intel, et dans le doute, je les ai essayées. Ça m'a changé la vie, car mon xorg, et accessoirement mon kde est beaucoup plus fluide maintenant.
Pour info, ma carte video est une intel Mobile 915GM/GMS/910GML Express Graphics Controller (rev 04) sur un portable fujitsu-siemens 7020S.
Je n'aurais qu'une question, où peux-t-on trouver de la doc sur les options à passer pour tel ou tel chipset, quelle méthode d'accélération utiliser, avec quelles options, etc ?
J'ai évidement cherché le web avant de poser la question ici, mais je n'obtiens que de vieux threads moisi datant de mathusalem, et n'expliquant rien du tout, ou bien peu de choses.
D'ailleurs, en fait, ce que trouverai idéal, ce serait une doc donnant les paramètres optimums pour chaque chipset, pour autant qu'un tel document existe.
En tout cas, merci pour ton commentaire, car il m'a bien rendu service.
[^] # Re: XAA et 7.3
Posté par Victor . Évalué à 3.
[^] # Re: XAA et 7.3
Posté par ErrTu . Évalué à 3.
[^] # Re: XAA et 7.3
Posté par Gyro Gearllose . Évalué à 8.
En effet, la doc m'éclaircit énormément, en voici d'ailleurs un extrait :
Option 'ColorKey' 'integer'
This sets the default pixel value for the YUV video overlay key. Default: undefined.
Mouais, ben sans vouloir être méchant, ce genre d'aide et rien c'est pareil. Enfin, non, car au moins, je sais qu'il y a une option pour définir la couleur de la clef de recouvrement. Super !
Sans blague, je ne comprends pas pourquoi ce genre de pilote n'active pas par défaut les options qui donnent la patate à la machine, d'une, et de deux, pourquoi les options sont si peu documentées ?
Attention, hein, je ne voudrais pas que l'on comprenne de mon commentaire que je crache sur ceux qui contribuent au libre, quels qu'ils soient (bénévoles ou payés pour), je veux juste mettre (une fois encore ?) le manque de documentation claire sur ce point particulier.
[^] # Re: XAA et 7.3
Posté par ErrTu . Évalué à 6.
[^] # Re: XAA et 7.3
Posté par seginus . Évalué à 6.
Le pilote est écrit pour l'ensemble des puces. Hors, ces développeurs n'ont pas accès à tout les modèles de cartes. Il publie donc une doc disant à quoi sert les options qu'ils ont implenté pour que les gens puissent savoir à quoi elles servent et ainsi testé sur leur matériel.
Ce qu'il faudrait dans un premier temps, c'est une sorte de wiki ou autre pour que les gens mettent en ligne suivant leur chipset les options les plus efficaces.
Intégré directement dans Xorg ? le problème je pense viens du fait que cela dépend des cartes voir peut-être même d'autres éléments dans la configuration et que l'on ne peut donc pas « pondre » un fichier xorg générique et performant.
À terme par contre si une telle base de donnée est crée pourquoi pas faire un script de configuration pour leur cartes qui irait scruté dans les informations du systèmes pour voir les options les plus efficaces en se basant sur la base de donnée ainsi créer (et qui pourrait être mis à jour).
Ce n'est que des suppositions, je ne sais pas du tout comment se passe le développement des pilotes intel.
[^] # Re: XAA et 7.3
Posté par ribwund . Évalué à 3.
Ce n'est que des suppositions, je ne sais pas du tout comment se passe le développement des pilotes intel.
À mon avis, c'est pas ça (vu que c'est intel qui développe les pilotes, ils doivent avoir accès aux cartes).
[^] # Re: XAA et 7.3
Posté par imr . Évalué à 2.
...
Et ca va beaucoup mieux.
Je viens d'essayer ces paramètres, et ça va beaucoup mieux aussi, EXA a maintenant le niveau de performances de XAA avec les effets activé de KDE4.
Par contre, si je lance vlc avec les effets activés, je n'ai aucune amélioration avec ces options, c'est du 7 frames/s. Si je désactive les effets, ça redevient fluide.
Testé sur 2 machines avec i915 et i945.
Une idée de l'origine du problème? Ou une autre option qui pourrait impacter?
[^] # Re: XAA et 7.3
Posté par dinomasque . Évalué à 3.
BeOS le faisait il y a 20 ans !
[^] # Re: XAA et 7.3
Posté par imr . Évalué à 2.
Voila ou j'en suis, testé sur 2 machines, i915 et i945:
XAA effets activés:
normal: 60 FPS
effets fenetres gélatine: 21 fps
vlc ou tv time plante.
vlc
Error of failed request: BadAlloc (insufficient resources for operation)
tvtime:
Cannot allocate enough off-screen video memory. This may be fixed by:
1. Closing or restarting large X applications.
2. Lowering the input width of tvtime (--inputwidth parameter).
3. Lowering your colour depth or highest configured resolution.
4. Increasing the amount of video memory in your X config file
(for example, if you are using the i810 XFree86 driver.)
EXA effets activé:
normal: 60 FPS
effets fenetres gélatine: 7 fps
vlc rame mais ne plante pas. 7-8 fps)
EXA effets activés plus les options conseillées dans ce fils:
normal: 60 FPS
effets fenetres gélatine: 21 fps
vlc rame mais ne plante pas. 7-8 fps)
XAA sans les effets sans les options:
vlc ne plante pas, ~21fps.
drivers NVIDIA proprio saimal les drivers libres saimieux sadoimarchaimieux:
aucun problème avec vlc tous les effets activés.
Ca me semble un problème d'allocation de la mémoire vidéo par les drivers intel. tvtime qui lague un peu conseille dans ce genre de cas d'essayer l'option VideoRam qui permet d'allouer plus de mémoire partagée. Mais la man page intel dit que cette option n'est plus évaluée, que les drivers gère ça eux même automagiquement.
[^] # Re: XAA et 7.3
Posté par imr . Évalué à 2.
Avec l'option CPU > minimiser le nombre de thread, il se lance et il atteint +20 FPS. Par contre, il saccade, le son est décallé et changer de chaine rame complètement.
[^] # Re: XAA et 7.3
Posté par benoar . Évalué à 3.
Après, c'est vrai que c'est une intégrée, et que donc on doit pouvoir régler la taille allouée en mémoire centrale ... En tous cas, c'est sûr que ce n'est pas l'option VideoRam. Essaye de voir dans le BIOS si tu peux l'augmenter.
[^] # Re: XAA et 7.3
Posté par imr . Évalué à 2.
# UMA seulement ?
Posté par benoar . Évalué à 10.
- UMA veut dire "Uniform Memory Architecture", par opposition à NUMA, le genre de truc qu'on trouve dans les très gros serveurs/clusters quand on parle de calcul généraliste avec des mémoires qui fonctionnent différemment
- Mais dans notre cas, qui se rapporte aux cartes vidéos, on parle de comment est partagées la RAM et la mémoire vidéo
- Donc ici, si on parle d'UMA, on parle _uniquement_ des cartes vidéos qui utilisent la mémoire centrale comme frame buffer et autre mémoire nécessaire à la carte vidéo
- Donc c'est uniquement pour les cartes vidéos intégrées, ce qui plait bien à Intel puisqu'ils ne font que ça ....
Bref, c'est bien pour Intel, mais pour les autres .... enfin, s'ils font des IGP, ça peut les intéresser.
Rappelons que GEM est aussi une création pure Intel, pour "contrer" le TTM de Tungsten Graphics (qui ont aussi fait le DRI).
D'ailleurs, les problèmes de registres write-combining/write-back sont adressés dans TTM il me semble, donc quand il dit que c'est un problème .... c'est un problème pour GEM, qui a choisi une architecture simplifiée (je ne dis pas que c'est mal, je dis qu'il faut réfléchir au pour et au contre).
Voilà, c'est un post un peu critique, mais faut voir ce qu'il se passe en ce moment avec Intel : ils font "bouger" les choses en "emmerdant" tout le monde (i.e. en refaisant de zéro des trucs qui sont déjà en développement), ce qui d'un coté est pas mal car cela lance le débat, mais cela se fait de manière un peu brutale en essayant de "forcer" tout ça upstream afin d'être les premiers intégrés, et donc comme souvent, le seul qui restera ... (vous savez, le principe d'être présent par défaut, partout ...)
[^] # Re: UMA seulement ?
Posté par Stephane Marchesin (site web personnel) . Évalué à 7.
Oui c'est exactement ça, j'ai l'impression qu'il y a chez intel une vague de Not_Invented_Here en ce moment. C'est très malsain, ils sont en train de faire la même chose pour le noyau où ils prétendent que GEM va marcher partout...
[^] # Re: UMA seulement ?
Posté par Matthieu . Évalué à 3.
Sinon, bon courage et bonne continuation pour ce projet que nous sommes nombreux à suivre et à attendre :-)
[^] # Re: UMA seulement ?
Posté par Stephane Marchesin (site web personnel) . Évalué à 5.
Comme GEM ne fonctionne pas en l'état avec les cartes non-integrées (il ne gère pas la ram video, juste la ram système partagée), il faudra effectivement des adaptations (pour nouveau, pour radeon, pour toutes les cartes séparées en fait). TTM le fait, même si le code est plus complexe.
[^] # Re: UMA seulement ?
Posté par ribwund . Évalué à 2.
[^] # Re: UMA seulement ?
Posté par Stephane Marchesin (site web personnel) . Évalué à 2.
Oui, surtout parce que les gens de intel (du noyau et des drivers video) bossent entre eux. Mais si il y a collaboration avec le kernel, mais pas avec les autres drivers, avoue que c'est un peu ennuyeux.
[^] # Re: UMA seulement ?
Posté par patrick_g (site web personnel) . Évalué à 1.
[^] # Re: UMA seulement ?
Posté par benoar . Évalué à 4.
Pourquoi dis-tu qu'il est "quasi-évident" qu'il va rentrer ? Il y a du favoritisme upstream pour Intel ? Linus aime bien les trucs simples et il est pragmatique, c'est peut-être ce qui le fait pencher pour ça, mais l'"effet réseau" provoqué par une adhésion rapide mais pas très réfléchie à un composant/API peut être dévastateur pour tout autre alternative.
Franchement, je trouve ça bizarre qu'on fasse rentrer un composant censé unifier l'accélération graphique, tout en étant fait uniquement pour un constructeur pour le moment (et qui n'a été "designé" que pour leur type de carte - s'ils voulaient vraiment un truc générique, pourquoi n'ont-ils pas fait une "surcouche" simplifiée à TTM ?)
[^] # Re: UMA seulement ?
Posté par yannig (site web personnel) . Évalué à 3.
[^] # Re: UMA seulement ?
Posté par benoar . Évalué à 2.
Mais un peu de réflexion ferait du bien, j'ai l'impression de me retrouver dans la vie d'aujourd'hui où on prend toujours le moins cher, sans réfléchir aux conséquences. Ce n'est pas parce que c'est le plus simple que c'est forcément mieux ...
[^] # Re: UMA seulement ?
Posté par patrick_g (site web personnel) . Évalué à 5.
Il me semble que ta remarque ne s'applique pas du tout aux gardiens des portes du noyau (Linus Torvalds et Andrew Morton).
Je leur fait confiance pour n'accepter un truc qu'après avoir réfléchi d'abord.
[^] # Re: UMA seulement ?
Posté par benoar . Évalué à 2.
C'est toujours le problème de "ceux qui font" : je suis d'accord que c'est mieux que de ne rien faire, mais parfois c'est juste pour "occuper le terrain", ou "faire du vent", et ça a beau être rentable pour le court terme, sur le long terme ça l'est moins en général. Après, peut-être que les devs du kernel juge que cela suffit, et qu'on aura mieux après, mais ça recule d'autant plus le "mieux après".
[^] # Re: UMA seulement ?
Posté par Stephane Marchesin (site web personnel) . Évalué à 2.
Oui, d'un côté il y a les gens de Red Hat et de ATI/AMD qui sont en train d'essayer d'adapter GEM/TTM (de prendre le meilleur de chaque) pour en faire quelque chose d'utilisable pour tout le monde. Et de l'autre côté, intel court-circuite le chemin "habituel" que prennent les patches DRM (normalement ils passent par le mainteneur du DRM) et les envoient directement à la lkml.
[^] # Re: UMA seulement ?
Posté par Stephane Marchesin (site web personnel) . Évalué à 5.
Le problème est que comme GEM a été développé (en secret, sans aucune discussion avec les autres devs) par intel et pour intel, il n'est pas vraiment "future proof". Mais bon, je suppose que dans 2 ans on refera autre chose...
Et sur le long terme, j'ai bien peur qu'intel monopolise tout le graphique sous linux, il n'y a pas de boîte qui investit assez pour les contrer aujourd'hui. Donc dans 5 ans on pourrait se retrouver dans une situation où seulement les cartes intel marchent bien sous linux. Et on aura droit à des "mouah linux c'est nul ma carte video marche pas dessus".
PS: je pense que j'ai écrit assez de code dans le domaine des drivers video pour éviter d'être accusé de "grogner" sans rien faire.
[^] # Re: UMA seulement ?
Posté par claudex . Évalué à 5.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# Que du pipo
Posté par Stephane Marchesin (site web personnel) . Évalué à 7.
Pourquoi vous allez me dire ? Tout simplement parce que lors de l'adaptation de EXA à GEM [1] [2], Keith Packard n'a pas voulu modifier EXA pour le faire fonctionner avec GEM (ça aurait encore tout cassé) mais plutôt séparer les 2 travaux en dupliquant EXA ailleurs pour ensuite supprimer/adapter le code là où il y avait besoin. Le bébé fait 5000 lignes là où EXA fait environ 7500 lignes et Keith a donc décidé de l'appelé UXA (UMA Acceleration Architecture. Et UMA ? Mystère ...).
Et d'ailleurs 5000 lignes + 7500 lignes de code à maintenir, c'est moins que juste 7500 lignes à supporter pour les devs de X.Org. J'ai bon ?
En plus, EXA permet déjà de faire tout ce que fait UXA. Alors je veux bien que tu m'expliques à quoi ça sert de faire une nouvelle archi.
Après l'intégration de la gestion du mode de la carte graphique dans le kernel ainsi que l'apparation prochaine de GEM dans le kernel, on ne peut que se réjouir de ces changements qui laisse entrevoir un avenir radieux pour l'accélération graphique sous Linux. Imaginez plutôt :
Oui c'est radieux, pour preuve, on a GEM et UXA, deux composants qui sont spécifiques aux cartes intel. Ca va être bien pour tout le reste du matos.
[^] # Re: Que du pipo
Posté par ʭ ☯ . Évalué à 1.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Que du pipo
Posté par patrick_g (site web personnel) . Évalué à 5.
[^] # Re: Que du pipo
Posté par Stephane Marchesin (site web personnel) . Évalué à 2.
Hum, on parlait pas du graphique là ? :) A mon avis il n'y a pas de problème avec ce que fait intel hors du graphique, le problème c'est qu'à l'intérieur d'intel toutes les équipes ne fonctionnent pas pareil.
Je suppose (et j'espère) que c'est lié à la relative "jeunesse" des drivers video dans le noyau (à comparer au support des cpu/chipsets qui a eu bien plus de temps pour arriver à maturation).
# Généralisation du modèle de programmation d'un GPU...
Posté par GPL . Évalué à 4.
On a, grosso modo, AMD, NVIDIA et Intel qui a décidé de devenir sérieux sur les GPUs (pas avant l'année prochaine, voir 2 ans...).
Les GPUs semblent diverger significativement en terme de modèle de programmation, et généraliser un modèle qui conforte les 3 acteurs du marché, et bien au niveau de la programmation bas niveau, pifométriquement je pense que ç'est pas trop gagné. J'ai cru comprendre, sur en survolant les MLs concernées, que le TTM est particulièrement complexe comparé au GEM (ça serait la complexité du TTM qui aurait poussé K.P. a l'envoyé au Diable).
Par contre, on annonce la release d'opengl3 au siggraph 2008 dans quelques jours et là, tous le monde est supposé être d'accord sur le modèle. Par contre il faudra implémenter GL3 avec les différentes interfaces bas niveau de chaque GPU, à moins que Gallium3D fasse la couche intermédiaire, et que ce soit cette dernière qu'il faille implémenté pour chaque interface de GPU.
Une interface bas niveau généralisée à tous les GPUs est intuitivement plus complexe que si on avait une interface bas niveau par GPUs. Il ne faut pas oublier que le cout logiciel est représenté par la taille du code modulo sa complexité (cela impacte directement la facilité de maintenance). Où est le juste milieu pour le cas des GPUs?
Bon là dessus, je pense que marcheu a une bien meilleur vision des choses pour répondre à ce genre de question et vu comment il n'a pas l'air d'accord... ça ne me dit rien qui vaille.
[^] # Re: Généralisation du modèle de programmation d'un GPU...
Posté par glisse . Évalué à 10.
Enfin une telle unification se ferait au détriment d'un acteur, celui qui a le meilleur driver. Si un même driver peut faire fonctionner les différentes cartes alors les investissements fait dans l'écriture de celui-ci profiteraient à la concurence. Je doute qu'aucun des trois acteurs est envie d'aller dans ce sens.
Le problème dont il est ici question est tout autre (GEM vs TTM). Durant de longue années il n'y pas eu de gestionnaire de mémoire digne de ce nom sous linux. Aujourd'hui certaines cartes graphiques ont plus de mémoire qu'il n'y de RAM dans l'ordinateur. Par ailleurs les gouleaux d'étranglement continuent de se multiplier. Le débit entre le GPU et sa mémoire est sans commune mesure avec celui du CPU avec la RAM. De même le débit entre la RAM et le GPU peut être particuliérement impacté par l'architecture et je pense ici notament aux architectures NUMA qui semblent être la voie choisit pour le futur.
Il devient donc évident qu'on ne peut se permettre de gérer la mémoire vidéo à la légére et qu'il faut minimiser le déplacement des objets entre VRAM et RAM. GEM est conçu dans le cadre de carte qui n'ont pas de VRAM, il n'a donc pas exactement les mêmes objectifs. TTM est bien trop complexes (une bonne métaphore : "take a gun to kill a fly").
Enfin le fond du problème ici c'est qu'intel a mit les moyens pour le dévelopement de drivers video efficaces sous linux pour son matériel. Si aucun des autres constructeurs NVidia ou AMD ne fait de même, on risque de se retrouver avec une infrastructure qui s'adaptera mal avec les cartes ayant leur propre mémoire vidéo. Tout revient donc à une question de moyens, d'argent. Il faut prendre conscience qu'aujourd'hui le dévelopement du noyau est gouverné par ceux qui investissent de l'argent dedans, ce qui me semble normal dans le cadre des régles qui régissent les interactions dans nos sociétés au sens large.
[^] # Re: Généralisation du modèle de programmation d'un GPU...
Posté par Aissen . Évalué à 2.
J'aimerai ajouter que le point de vue d'Intel est tout à fait compréhensible: il n'iront pas faire un cadeau à AMD en investissant dans dans une architecture qui bénéficie à tout le monde; c'est un peu contraire à la philosophie du noyau d'ailleurs, mais comme il n'y a rien en place et qu'ils sont les premiers, personne n'a rien à redire.
Maintenant est ce que ce n'est pas se tirer une balle dans le pied pour le moyen terme avec en:Larrabee_(GPU) qui arrivera à l'horizon 2010 (voire fin 2009) ?
Enfin, tout cela est à mettre en perspective avec Nvidia qui a un des meilleurs drivers au niveau performance sous linux. Le LHB a fait un article là dessus: http://linuxhaters.blogspot.com/2008/06/nitty-gritty-shit-on(...) c'est à prendre avec des pincettes, et il faut mettre de coté le ton haineux, mais je trouve que l'article n'est pas dénué d'intérêt.
À opposer à l'analyse (tout aussi intéressante) du kernel hacker James Bottomley: https://www.linuxfoundation.org/en/Linux_Graphics_Essay . Nvidia a un des drivers qui génère le plus de crash et lag le plus pour les corrections de bugs.
# j'ai achete un portable avecu un carte intel
Posté par RB . Évalué à 3.
A lire tout ca, je suis un peu decu, aussi par Keith Packard. Je comprend pas trop, a l'heure ou ATI a ouvert ses specs et que des gens travaillent sur des drivers ouverts, qu'il n'y aie pas une convergence, au moins entre les constructeur qui ouvrent leur materiel.
# J'ai eu peur
Posté par Denis Montjoie (site web personnel) . Évalué à 2.
Je suis rassuré.
Quoi que, sur un serveur, ca pourrait etre utile? Déjà que les GPU peuvent être détournés de leur utilisation première...
[^] # Re: J'ai eu peur
Posté par Frédéric Heulin . Évalué à 5.
http://gentoo-wiki.com/TIP_Use_memory_on_video_card_as_swap
[^] # Re: J'ai eu peur
Posté par benoar . Évalué à 2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.