Se connecter avec
S'enregistrer | Connectez-vous

AMD ouvre des codes pour ses Radeon HD 5000

Par - Source: Phronix | B 17 commentaires

AMD vient de publier les codes sources facilitant l’accélération matérielle sur les Radeon HD 5000 Evergreen, ce qui devrait grandement profiter à la communauté Linux qui pourra optimiser la prise en charge de 2D EXA, X-Video et l'OpenGL.

En février dernier, AMD avait apporté la gestion de l’Evergreen KMS, ce qui a permis concrètement au noyau Linux 2.6.34 de prendre en charge les fonctionnalités basiques de la carte sans pour autant être compatible avec X-Video et 2D EXA. Jusqu’à présent, les utilisateurs du système d’exploitation au manchot possédant une carte graphique Evergreen ne disposaient que des pilotes binaires souvent bugé et ternis par une mauvaise réputation et si ces pilotes restent le choix par défaut pour les utilisateurs désireux de profiter de toutes les fonctionnalités du GPU, l’accélération matérielle par les Radeon HD 5000 de certains composants graphiques devrait améliorer les performances de l’OS sous ces cartes. La communauté espère maintenant qu’AMD publiera les mêmes codes pour les Radeon HD 6000 plus rapidement que ce qu’il n’a fait pour les Radeon HD 5000 où il a fallu attendre presque un an après leur commercialisation.

Commentaires
Interroger un expert

Votre question aux experts de la catégorie Les news : vos réactions du forum

Exemple : Android, ordinateur portable, usb, disque dur

Cette page n'accepte plus de commentaires
Meilleurs commentaires
  • 17 Masquer
    mitch074 , 23 août 2010 10:03
    Pour être totalement franc...

    Les pilotes binaires AMD se sont fortement améliorés ces deux dernières années (depuis le rachat d'Ati par AMD, en fait).

    Ils sont passés de machins infâmes, lents et instables à un état plutôt satisfaisant:
    - depuis la version 9.8, les fonctionnalités OpenGL sont correctement rapportées par le pilote, ce qui a entraîné un sacré gain de vitesse sous Wine, par exemple (où une partie des fonctionnalités, supportées jusqu'à présent en mode logiciel, sont passées accélérées).
    - depuis la version 10.3, un paquet de fuites mémoire a été progressivement supprimé; la version 10.7 (actuellement disponible) s'avère assez stable.
    - depuis maintenant pas mal de temps, l'installateur fournit en option la possibilité de générer des paquetages selon la distribution et la version de celle-ci, ce qui permet une installation/désinstallation propre et nette.

    Pour rappel, à une époque sur les fora de Wine, on disait: "t'as une Ati? T'es fichu. Achète une Nvidia." Maintenant, t'as une Ati, t'as juste besoin de veiller à bien avoir la dernière version du pilote.

    AMD a donc fait de sacrés efforts.

    En ce qui concerne le code source, AMD est obligé de le faire passer par l'approbation du département légal (parce qu'il y a de la propriété intellectuelle dans le matériel qui n'appartient pas à AMD, ils n'ont donc pas le droit de publier de pilote pour ces éléments protégés) - et le code de gestion d'Evergreen (le nom de code des RadeonHD 5xxx), bien que prêt depuis des mois, est bloqué au service légal.

    D'ailleurs, c'est bien dit dans l'article: les capacités d'initialisation et de réglage de la carte (KMS=Kernel Mode Setting) sont dispo depuis février; AMD n'avait libéré la documentation que pour le KMS, mais la puce étant assez similaire aux R700, une partie du code d'accélération 2D/3D avait pu être réutilisée - il fallait par contre que ce dernier soit prêt, et le code d'accélération R700 n'est vraiment stable que depuis avril (pour la sortie d'Ubuntu 10.04 LTS Lucid Lynx).

    Et encore, ledit code était très peu complet et vraiment lent (support limité à OpenGL 1.5, et à peu près 7 fois plus lent que le pilote binaire).

    Y'a eu des progrès, depuis. 'Faut aller sur le site de Phoronix (en anglais) pour avoir des nouvelles un peu plus fraîches.
Tous les commentaires
  • 17 Masquer
    mitch074 , 23 août 2010 10:03
    Pour être totalement franc...

    Les pilotes binaires AMD se sont fortement améliorés ces deux dernières années (depuis le rachat d'Ati par AMD, en fait).

    Ils sont passés de machins infâmes, lents et instables à un état plutôt satisfaisant:
    - depuis la version 9.8, les fonctionnalités OpenGL sont correctement rapportées par le pilote, ce qui a entraîné un sacré gain de vitesse sous Wine, par exemple (où une partie des fonctionnalités, supportées jusqu'à présent en mode logiciel, sont passées accélérées).
    - depuis la version 10.3, un paquet de fuites mémoire a été progressivement supprimé; la version 10.7 (actuellement disponible) s'avère assez stable.
    - depuis maintenant pas mal de temps, l'installateur fournit en option la possibilité de générer des paquetages selon la distribution et la version de celle-ci, ce qui permet une installation/désinstallation propre et nette.

    Pour rappel, à une époque sur les fora de Wine, on disait: "t'as une Ati? T'es fichu. Achète une Nvidia." Maintenant, t'as une Ati, t'as juste besoin de veiller à bien avoir la dernière version du pilote.

    AMD a donc fait de sacrés efforts.

    En ce qui concerne le code source, AMD est obligé de le faire passer par l'approbation du département légal (parce qu'il y a de la propriété intellectuelle dans le matériel qui n'appartient pas à AMD, ils n'ont donc pas le droit de publier de pilote pour ces éléments protégés) - et le code de gestion d'Evergreen (le nom de code des RadeonHD 5xxx), bien que prêt depuis des mois, est bloqué au service légal.

    D'ailleurs, c'est bien dit dans l'article: les capacités d'initialisation et de réglage de la carte (KMS=Kernel Mode Setting) sont dispo depuis février; AMD n'avait libéré la documentation que pour le KMS, mais la puce étant assez similaire aux R700, une partie du code d'accélération 2D/3D avait pu être réutilisée - il fallait par contre que ce dernier soit prêt, et le code d'accélération R700 n'est vraiment stable que depuis avril (pour la sortie d'Ubuntu 10.04 LTS Lucid Lynx).

    Et encore, ledit code était très peu complet et vraiment lent (support limité à OpenGL 1.5, et à peu près 7 fois plus lent que le pilote binaire).

    Y'a eu des progrès, depuis. 'Faut aller sur le site de Phoronix (en anglais) pour avoir des nouvelles un peu plus fraîches.
  • gento_koken , 23 août 2010 11:07
    Merci mitch, mais j'ai une question (surtout ne ralez pas ^^), y'aura t'il un jour dans un futur proche un direct 3D made in linux afin de profiter pleinement des jeux sur ces différents système?
    Merci
  • Afficher les 17 commentaires.
  • muc73 , 23 août 2010 11:09
    Contribution excellente. Merci de peindre tes expériences.
  • eat your potato , 23 août 2010 11:30
    gento_kokenMerci mitch, mais j'ai une question (surtout ne ralez pas ^^), y'aura t'il un jour dans un futur proche un direct 3D made in linux afin de profiter pleinement des jeux sur ces différents système?Merci


    Euh, soit j'ai pas compris ta question, soit tu ne connais pas OpenGL.

    PS : oui je sais, je ne m'appelle pas mitch074 ^^
  • -5 Masquer
    gento_koken , 23 août 2010 12:03
    Bah je pense que Direct3D profite de l'accélération matériel contrairement à OpenGl non ? ^^
    De plus si l'OpenGl s'intègre plus facilement au système Linux c'est qu'il est entièrement programmé en C.
    Enfin corrigez moi si j'ai faut :) 
  • zozolebo , 23 août 2010 12:14
    Il s'agit là d'un grand bond en avant dans l'histoire de Linux, je pense.

    En effet, un des freins majeurs à l'adoption de Linux par de nombreux jeunes est le manque de performances dans les jeux vidéos avec ce système d'exploitation.

    Or, on sait qu'en matière de nouvelles technologies, les jeunes sont ceux qui tirent le changement et poussent les générations aînées à utiliser les nouveaux produits.

    Jusqu'à présent, seul un public averti pouvait avoir accès à des performances plus ou moins bonnes dans les jeux vidéos sous Linux, moyennant des heures de configurations et de bugs en tous genres.
    En permettant à la communauté de développer ses propres outils, il va être possible de démocratiser des drivers à hautes performances (puisque les développeurs officiels concentrent leurs efforts avant tout pour les drivers Windows). Cela permettra d'obtenir des performances à peu près égales sous Windows comme sous Linux, et permettra donc de démocratiser ce système d'exploitation auprès de nombreux joueurs qui refusaient pour une bonne partie de migrer totalement vers Linux à cause du manque de performances.

    Maintenant, il va falloir que les concepteurs de jeux vidéos sortent des versions plus seulement pour Windows mais également pour Linux. Ce n'est pas encore gagné, mais maintenant qu'ils savent que les performances seront au rendez-vous, peut être pouvons nous espérer voir les prochains grands titres de jeux vidéos portés sous Linux !
  • zozolebo , 23 août 2010 14:08
    Citation :
    Bah je pense que Direct3D profite de l'accélération matériel contrairement à OpenGl non ? ^^

    Donc pour préciser les choses : OpenGL = Direct3D version libre. Techniquement, c'est exactement la même chose, sauf que Direct3D est développé par Microsoft avec des codes sources propriétaires, et OpenGL par un consortium avec des codes sources libres.

    Citation :
    De plus si l'OpenGl s'intègre plus facilement au système Linux c'est qu'il est entièrement programmé en C.

    Absolument pas. OpenGL est une API (comme Direct3D), ce qui signifie que la seule chose qui compte pour le développeur d'un jeux (par exemple), c'est la facilité d'utilisation de l'API. S'il programme son jeu en C ou C++, alors dans ce cas il est intéressant pour lui d'avoir une API en C ou C++. Mais le coeur d'OpenGL peut être programmé en assembleur, en C ou en Python, peu importe puisque le développeur ne verra que l'API. C'est d'ailleurs le but même d'une API : offrir au développeur un moyen simple d'utiliser des fonctions complexes. Le développeur ne voit que la "façade" (= l'API), les "fondations" (= le coeur du programme) étant très complexe et programmé dans n'importe quel langage. Tout ce qu'il faut, c'est que l'API soit du même langage que celui que le développeur utilise.

    Autre point : si OpenGL s'intègre aussi bien à Linux, ce n'est pas grâce à son langage de programmation (car je l'ai dis, il pourrait être programmé en Python), mais c'est grâce au fait qu'il est open source. Direct3D ne peut être porté sous Linux que si Microsoft décide de le programmer pour Linux, car ils sont les seuls à disposer des codes sources. On pourrait toujours bidouiller pour faire fonctionner Direct3D sous Linux, mais on perdrait énormément de performances. Ca n'a donc aucun intérêt puisqu'OpenGL fait la même chose que Direct3D, et qu'en plus OpenGL peut fonctionner sur n'importe quel système (contrairement à Direct3D qui se limite à Windows).
  • bebRito , 23 août 2010 14:17
    En voilà une bonne nouvelle !

    +1 avec mitch074, il faut arrêter les rumeurs sur les pilotes proprio instables et bugés, j'en voit encore sur le forums qui le pense, faute de ne pas avoir mis à jour. Les choses ont beaucoup changé, et c'est tant mieux !

    Par contre, il ne faut pas faire d'amalgame. Ne confondons pas prise en charge de l'accélération matérielle par un pilote correct (open source ou non) et la librairie utilisé dans un jeu pour la partie graphique.
    Actuellement, la plupart des jeux récents utilise DirectX. OpenGL a été délaissé par les développeurs de jeux pour une raison technique dont je ne me rappelle plus. Les constructeurs ont également suivi le mouvements en sortant des cartes toujours plus proches de DirectX.

    Il y a quand même plein de jeu qui sont censé fonctionner sous Linux : tous ceux qui utilise OpenGL. Après c'est sûr, si les éditeurs ne pensent pas à fournir un installeur spécifique, c'est plus difficile. Si je me souviens bien, le dernier CD d'Unreal Tournament 2003 disposait d'un installeur pour Linux.

    Après quand c'est du DirectX pur, il faut passer par Wine. Microsoft conserve ses librairies de manière privés, ca paraît logique pour eux : tu veux jouer -> achète une licence Windows. C'est dommage pour les linuxiens mais c'est comme ça et ca ne risque pas de changer.
  • Thill , 23 août 2010 15:17
    Fin bon, pour ce qui est de l'API, Carmack va de nouveau remettre les pendules a l'heure.

    Vu ces dernières demo sur iPhone, le moins que l'on puisse dire, c'est qu'il sait comment utiliser OpenGl, qui est selon moi, plus performant que Directx.

    L'avantage de Directx c'est que ce n'est pas seulement une API pour le rendu 3d, ca fait plein d'autres trucs comme la gestion du son... Ca semble plus pratique.
  • -1 Masquer
    bebRito , 23 août 2010 15:29
    C'est en effet un peu un abus de langage de dire que DirectX n'est qu'une API 3D, puisque cela regroupe en faite : Direct3D, DirectDraw, DirectSound, DirectMusic, DirectInput et DirectPlay (réseau).

    Après, dire que l'un est plus rapide que l'autre, c'est un très vieux débat ou plutôt une caverne de trolls ... :p 

    Avant, on avait le choix dans la plupart des jeux entre OpenGL et Direct3D (ex: Half Life 1). Selon la carte graphique, les perfs était mieux avec l'un ou l'autre.

    OpenGL accuse actuellement un gros retard par rapport à DirectX, ceci est dû au soucis de vouloir conserver d'anciennes fonctionnalités pour conserver la compatibilité avec certaines applications. La refonte prévue pour OpenGL 3 ne se fait pas de manière immédiate, comme on l'attendait.
    A cause de ce retard, les développeurs de jeux vidéos se sont davantage tournés vers DirectX ...

    (j'ai retrouvé une des explications, mais ce n'est pas la seule ;) )
  • pierreyoda , 23 août 2010 16:19
    bebRito.A cause de ce retard, les développeurs de jeux vidéos se sont davantage tournés vers DirectX ...(j'ai retrouvé une des explications, mais ce n'est pas la seule )


    Non, c'est surtout que DirectX est bien plus complet et plus facile à prendre en main que OpenGL (qui est en gros l'équivalent de Direct3D) (je suis moi-même développeur C++ amateur).
    De plus, lorsqu'on utilise un toolkit avancé (Ogre3D, Irrlicht...) on peut "switcher" entre OpenGL et DirectX pour le rendu, comme dans les anciens jeux dont tu parles.
  • mitch074 , 23 août 2010 16:22
    Bon, on va faire un peu plus complet...

    OpenGL est une spécification pour une API graphique complète, écrite à l'époque par Silicon Graphics et maintenue depuis l'an passé par le groupe Khronos, une coalition d'auteurs de logiciels graphiques et de fabricants de matériel. Dans ce groupe, on compte notamment Nvidia, Intel, AMD, Apple, Epic Games (en fait, tout le monde sauf 'Crosoft).

    Après, on parle d'implémentation de l'API OpenGL; sous GNU/Linux, on en compte trois grosses:
    - Nvidia (fournie avec le pilote proprio), laquelle a passé la suite de qualification (payante) d'OpenGL et peut donc s'appeler 'Nvidia OpenGL'
    - Ati/AMD (fournie avec le pilote proprio), laquelle a passé la suite de qualification (payante) d'OpenGL et peut donc s'appeler 'AMD OpenGL'
    - MesaGL, laquelle est une implémentation de référence comprenant un raster logiciel, et des pilotes accélérés pour différents bouts de matos (Intel, AMD libre, Nvidia "nouveau"), mais qui n'a pas payé la suite de qualification payante d'OpenGL (bien que l'auteur d'origine, Brian Paul, ait obtenu à l'époque le droit d'utiliser la suite de qualification sans payer, mais aussi sans utiliser le nom) - et ne peut donc pas s'appeler OpenGL (mais est compatible).

    Contrairement à Direct3D (qui est une API purement 3D), OpenGL peut servir à n'importe quel travail graphique (incluant un gestionnaire de bureau si vous voulez), même si celui-ci n'est pas rendu à l'écran (rendu de scènes 3D pour des films d'animation, par exemple); ça, chez 'Crosoft, il a fallu attendre Win7 (et Vista SP2) pour avoir l'équivalent: Direct2D (qui n'a rien à voir avec DirectDraw, une API d'ailleurs dépréciée) est une surcouche à Direct3D permettant l'interaction entre un rendu 3D et une couche 2D (en remplacement de GDI).

    En comparaison, par exemple, la première version du bureau 3D sous GNU/Linux, en 2005, utilisait un serveur compatible X11 (nommé XGL) qui tournait sur une instance OpenGL.

    La reprise d'OpenGL par le groupe Khronos a entraîné la très rapide mise à niveau des spécifications: on en est aujourd'hui à OpenGL 4.1 (prise en compte de la tesselation); le matos actuel est soit compatible OpenGL 3 (RadeonHD 2/3/4xxx, Geforce 8xxx/GT2xx) ou 4 (RadeonHD 5xxx, Nvidia Fermi). L'implémentation Mesa est par contre assez en retard, bien que plusieurs éléments faisant partie de la spécification 3.3 sont en cours de développement; actuellement, on peut tabler sur une compatibilité OpenGL 1.5 (shaders à fonction fixe), pour certains matos: OpenGL 2.1 (shaders programmables) et certains éléments de OpenGL 3.1. Un remplaçant du raster logiciel est en cours d'écriture, il permet déjà un rendu de type OpenGL 2.1 en software seulement - utile sur les machines multiprocesseurs avec des systèmes graphiques ridicules (exemple: le matos Intel) ou dépassé.

    Quel est l'avantage de OpenGL par rapport à Direct3D?
    - y'en a partout: Linux, BSD, Apple Mac, Android, et pas mal de systèmes embarqués.
    - on n'a pas besoin de payer 'Crosoft pour qualifier du matos 'compatible OpenGL' à chaque sortie du pilote: une fois la suite payée, on peut s'en servir pour plusieurs releases (ou même pas du tout), au lieu de devoir repayer chaque processus WHQL
    - on peut faire de la 2D avec sans changer d'API
    - on peut recompiler son code sur n'importe quelle plateforme, y'a pas besoin de réécrire le code graphique

    Par contraste, sous Windows, pour faire une version Windows Mobile, ou Mac, ou n'importe quoi d'autre, 'faut réécrire l'appli en entier - car 'Crosoft ne fournit Direct3D que sous Windows. De plus, Windows XP (encore 60% des usagers) ne supporte que D3D9 (alors que rien n'empêche une RadeonHD 5xxx de supporter OpenGL 4.1 sous WinXP), ce qui demande donc de:
    - programmer un jeu en DX9 et DX10, avec donc deux moteurs de rendu
    - ou faire l'impasse sur la moitié du marché
    - ou programmer le jeu avec un moteur graphique en OpenGL - et en profiter pour faire une version Mac.

    L'inconvénient, c'est que Visual Studio s'intègre très bien avec le SDK DirectX, mais n'a pas de SDK OpenGL à proprement parler (celui-ci est en fait fourni par les fabricants de matériel, ou alors le soft n'est pas développé sous Windows, mais uniquement porté sous Windows au final - c'est le cas de World of Warcraft, par exemple).

    Voilà l'explication: c'est plus facile de développer avec DirectX (parce qu'on peut dire plein de choses sur MS, mais leurs SDK sont hyper complets). Et comme pendant un moment, OpenGL était dans le flou total, ben les devs s'en sont désintéressés.

    Seulement, depuis un moment (la sortie de Vista, en fait, qui coïncide avec la sortie des netbooks et des smartphones dignes de ce nom comme l'iPhone ou le n95), les plateformes alternatives (phones mobiles, netbooks sous Linux, box de fournisseurs d'accès etc.) se sont développées et toutes ou presque tournent avec une variante d'UNIX ou un OS proprio - mais ont pour point commun de supporter une variante d'OpenGL. Donc, les éditeurs de jeux (du moins, ceux qui font des jeux pour un marché large, pas des éditeurs de fragfests où la config mini vaut 2000 €) se réintéressent à OpenGL - et de plus en plus d'apps fournissent donc un moteur alternatif OpenGL...

    Parce que sinon, s'il ne s'agissait que de la présence d'une API compatible DirectX sous UNIX, y'en a une, et elle marche pas mal: WineD3D! Seulement, cette API quoique plutôt complète (le support de DX10/11 a commencé) peut être un peu lente... car elle fonctionne comme traducteur D3D=>OpenGL. Parfois, le ralentissement est invisible, parfois, c'est moins le cas.

    Quelle serait la difficulté de recompiler une appli Windows en appli UNIX liée à Wine? Pas énorme - mais il n'y aurait pas non plus de gain par rapport à une appli Windows exécutée sous Wine (demandez à Google comment ils ont fait la version Picasa sous Linux) - sauf pour faire un portage vers ARM (ou n'importe quelle plateforme non x86). Mais là, on se retrouve face à un tel panier de crabe (endiannité des octets, taille des types d'entiers, threading, bouts d'assembleurs...) qu'il vaut mieux se simplifier la vie, et écrire un port OpenGL direct.
  • bebRito , 23 août 2010 16:31
    Citation :
    c'est surtout que DirectX est bien plus complet et plus facile à prendre en main que OpenGL
    J'aimerai bien que tu développes un peu car j'ai également fais du développement OpenGL avec SDL, Glu, Glut et SFML et je n'ai trouvé ces implémentations incomplètes ou difficiles, surtout SFML.

    Par contre, je n'ai jamais essayé DirectX.

    EDIT: @mitch074, super résumé, très détaillé, merci :D 
    +1 pour picasa !
    Et tu peux éditer tes message en passant par le forum ;) 
  • gento_koken , 23 août 2010 16:47
    J'en apprend vraiment des choses sur ce site, merci pour vos réponses :) 
  • shaeffer , 23 août 2010 17:20
    Ma HD5750 tourne très bien sous Linux. J'ai activé d'ailleurs l'accélération matérielle pour la lecture vidéo. Cependant celle-ci ne fonctionne qu'avec MPlayer.
  • mitch074 , 23 août 2010 17:22
    @bebRito: tu as développé avec SDL, Glu(t) et SFML? Donc tu n'as pas développé sous Visual Studio... :p 
    'Faut voir qu'il y a deux catégories de développeurs:
    - ceux qui sont capables de faire un logiciel avec Notepad (mais qui préfèrent un IDE costaud) et un compilateur en ligne de commande
    - ceux pour qui il faut trois SDK, 25 classes (et 47 instances) et 1450 ligne dans leur main loop pour programmer l'algorithme suivant: en affichant une suite numérique, afficher 'swizz' à la place des multiples de 3, 'bang' à la place des multiples de 5, et 'swizzbang' à la place des multiples des deux (oui, c'est pas facile de faire ça avec une interface Click'n'Drag)

    En gros, ceux qui programment parce que ça les amuse, et ceux qui sortent d'une école d'ingé/prog sans avoir jamais ouvert un bouquin de C (et de ce que j'ai pu personnellement constater, y'en a plus d'un; souvent, ils vous brandissent un certificat MSCP avec l'attente qu'on se mette à genoux devant eux).

    Et oui, je sais programmer cet algorithme en moins de 12 lignes en PHP ou Javascript ou Delphi; avec un gros bouquin, je devrais y arriver en C - mais j'y ai très peu de pratique.
  • bebRito , 23 août 2010 17:54
    Citation :
    Ma HD5750 tourne très bien sous Linux. J'ai activé d'ailleurs l'accélération matérielle pour la lecture vidéo. Cependant celle-ci ne fonctionne qu'avec MPlayer.

    Je crois que c'est un problème récurrent avec MPlayer.

    Citation :
    @bebRito: tu as développé avec SDL, Glu(t) et SFML? Donc tu n'as pas développé sous Visual Studio... :p 
    'Faut voir qu'il y a deux catégories de développeurs:
    - ceux qui sont capables de faire un logiciel avec Notepad (mais qui préfèrent un IDE costaud) et un compilateur en ligne de commande
    - ceux pour qui il faut trois SDK, 25 classes (et 47 instances) et 1450 ligne dans leur main loop pour programmer l'algorithme suivant: en affichant une suite numérique, afficher 'swizz' à la place des multiples de 3, 'bang' à la place des multiples de 5, et 'swizzbang' à la place des multiples des deux (oui, c'est pas facile de faire ça avec une interface Click'n'Drag)

    En gros, ceux qui programment parce que ça les amuse, et ceux qui sortent d'une école d'ingé/prog sans avoir jamais ouvert un bouquin de C (et de ce que j'ai pu personnellement constater, y'en a plus d'un; souvent, ils vous brandissent un certificat MSCP avec l'attente qu'on se mette à genoux devant eux).

    Et oui, je sais programmer cet algorithme en moins de 12 lignes en PHP ou Javascript ou Delphi; avec un gros bouquin, je devrais y arriver en C - mais j'y ai très peu de pratique.

    :lol: 

    Je peux développer sous XEmacs, Vi, Gvim, au choix :p 
    Mais il faut avouer qu'un Eclipse CDT aide un peu la tâche, notamment pour la completion : ca permet au moins de ne pas passer trop de temps (même s'il en faut quand même) à parcourir les docs pour connaître les librairies, et savoir ce qu'elles proposent.

    J'ai testé sous Windows (avec MinGW ou Cygwin) et sous ma Gentoo favorite bien sûr.
    C'était plutôt pour découvrir, je n'ai pas poussé bien loin.

    Mais pour répondre à la question de savoir si je code avec les pieds, bah j'espère que non ! Je ne suis pas ingénieur, j'ai un DUT Info. Et je suis d'accord avec toi qu'il y a vraiment certains ingénieurs qui feraient mieux de nous donner leur salaire plutôt que de prétendre à une quelconque connaissance en programmation.
    Il faut croire que leurs études se sont résumées à une fête d'intégration annuelle. Au passage, vu que tu me lances sur le sujet : merci aux employeurs de jouer le jeu en continuant d'embaucher uniquement sur CV, sans s'intéresser aux vraies compétences, sans faire attention lors la période d'essai et à devoir se débarrasser des si bons ingénieurs plus tard avec un motif toujours plus bidon que leurs méthodes de recrutement ... :kaola: 

    Ayé, mon coup de gueule est passé. Merci mitch074 :D