OpenCL, en version 1.0

Posté par (page perso) . Modéré par baud123.
21
10
déc.
2008
Technologie
OpenCL (Open Computing Langage) est un projet ambitieux, initialement lancé par Apple. Les spécifications ont été proposées et acceptées par le consortium Khronos, qui par ailleurs s'occupe aussi d'OpenGL, en juin 2008. La version 1.0 est sortie aujourd'hui (09/12/2008) et est disponible sur http://www.khronos.org/registry/cl/ (spécification et headers).

Le but de ce projet est de permettre aux développeurs de tirer parti des énormes capacités de calcul des processeurs graphiques (GPUs) d'aujourd'hui. En effet, sauf quand une application graphique est lancée (un jeu par exemple), cette puissance de calcul reste inutilisée pour la plupart du temps. On appelle ce genre de technique, qui consiste finalement à détourner l'utilisation principale d'un processeur graphique, « General Purpose Computing on Graphics processing Units » ou tout simplement, GPGPU.

OpenCL permet donc de consolider la puissance de calcul absolue des machines en utilisant le GPU comme un simple CPU, et donc d'utiliser ce CPU « virtuel » pour les besoins de n'importe quel type d'application. Cette technologie sera incluse dans Mac OS X v10.6 (Snow Leopard) et normalement strictement transparente pour les applications. Le package OpenCL + transparence pour les programmes répond au doux nom marketing « Grand central », et ce regroupement ne sera évidemment pas libre. Cependant, rien n'empêchera au monde du libre de l'adapter dans un « Grand Central » complètement libre.

La spécification est définie comme ouverte et libre de droit. Malheureusement, il m'a été impossible de trouver une quelconque licence ou de quelconques démos. Confidentialité sur Snow Leopard oblige...

Cependant, un grand nombre d'acteurs se sont joints au projet et aujourd'hui on trouve, entre autres : Apple, AMD, NVIDIA, Intel, Broadcom, Blizzard, EA, Ericsson, IBM, Movidia, Nokia, Sony, Symbian, Texas Instruments. Bref, on ne trouve que du beau monde.

Cette technologie, définie comme indépendante du matériel, pourra potentiellement donner un grand coup de fouet aux capacités de calcul de nos machines actuelles. Il ne reste plus qu'à espérer qu'elle soit réellement « open and royalty-free ».

NdM : Afin d'éviter que CUDA (la technologie propriétaire qui est soutenue par NVidia) ne s'empare totalement de ce nouveau marché, les autres acteurs se sont regroupés derrière la bannière d'OpenCL. Cette technologie va donc bien au delà de MacOS X et elle va sans doute devenir "la" technologie de GPGPU sur les systèmes libres.
  • # Benchmark

    Posté par (page perso) . Évalué à 5.

    Ce serait intéressant de savoir si Phoronix va faire un comparatif entre les deux technologies. Je présume que si Nvidia s'est joint au projet, c'est qu'il est possible d'utiliser leur GPUs avec les deux technologies ?
    • [^] # Re: Benchmark

      Posté par . Évalué à -1.

      ça serait bien d'avoir des drivers ATI qui ne plantent pas déjà ...

      et qui affichent les vidéos sans déchirement
      • [^] # Re: Benchmark

        Posté par . Évalué à -1.

        Tu as au moins remonté le bug que tu as décelé?

        Tu es libre de proposer un patch si tu peux en coder un (ce qui n'est pas mon cas, je dois l'avouer).
        • [^] # Re: Benchmark

          Posté par . Évalué à 3.

          sur le driver fglrx ça va être dur

          et sur le driver libre je leur jette pas la pierre
          elle est réservée à ATI
          un beau granit
  • # licence

    Posté par (page perso) . Évalué à 9.

    Trouvé dans cl.h

    /*******************************************************************************
    * Copyright (c) 2008 The Khronos Group Inc.
    *
    * Permission is hereby granted, free of charge, to any person obtaining a
    * copy of this software and/or associated documentation files (the
    * "Materials"), to deal in the Materials without restriction, including
    * without limitation the rights to use, copy, modify, merge, publish,
    * distribute, sublicense, and/or sell copies of the Materials, and to
    * permit persons to whom the Materials are furnished to do so, subject to
    * the following conditions:
    *
    * The above copyright notice and this permission notice shall be included
    * in all copies or substantial portions of the Materials.
    *
    * THE MATERIALS ARE PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
    * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
    * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
    * IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
    * CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
    * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
    * MATERIALS OR THE USE OR OTHER DEALINGS IN THE MATERIALS.
    ******************************************************************************/
    • [^] # Re: licence

      Posté par . Évalué à 2.

      Ca semble être la même que pour OpenGL :

      /*
      * Mesa 3-D graphics library
      * Version: 6.5.1
      *
      * Copyright (C) 1999-2006 Brian Paul All Rights Reserved.
      *
      * Permission is hereby granted, free of charge, to any person obtaining a
      * copy of this software and associated documentation files (the "Software"),
      * to deal in the Software without restriction, including without limitation
      * the rights to use, copy, modify, merge, publish, distribute, sublicense,
      * and/or sell copies of the Software, and to permit persons to whom the
      * Software is furnished to do so, subject to the following conditions:
      *
      * The above copyright notice and this permission notice shall be included
      * in all copies or substantial portions of the Software.
      *
      * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
      * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
      * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
      * BRIAN PAUL BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN
      * AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
      * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
      */
      • [^] # Re: licence

        Posté par (page perso) . Évalué à 4.

        Ça c'est la licence de Mesa3D, une implémentation libre d'OpenGL.
        Silicon Graphic a sorti OpenGL Sample Implémentation avec une licence libre (similaire à Mozilla), mais il n'est plus très à jour. Mesa3D est la version libre et logicielle la plus complète. Voir la FAQ sur http://www.mesa3d.org/faq.html et les licences sur www.opengl.org

        "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

  • # J'ai un peu de mal avec le concept.

    Posté par . Évalué à 7.

    Est-ce que ça signifie que le programme est transformé en exécutable pour le GPU au vol, ou bien c'est fait pour tous les processeurs supportant opencl à la compilation, ou bien c'est une programmation de type script avec une sorte d'interprète implémenté dans le driver du GPU?

    Bref ça marche comment?
    • [^] # Re: J'ai un peu de mal avec le concept.

      Posté par . Évalué à 7.

      Ben ch'uis pas expert non plus, mais je suppose que là il faut distinguer 2 choses:

      - OpenCL lui-même qui est un langage, que tu dois utiliser explicitement si tu veux accéder au GPU "brut de forme"

      - la partie "Transparence" développée pour l'instant par Apple, qui je suppose est en fait une recompilation des bibliothèques pour envoyer les instructions adaptées vers le GPU (pour Linux, ce serait en premier la glibc2/libc6, peut-être d'autres?), ces modifications ayant été programmées en (roulement de tambours) OpenCL!
    • [^] # Re: J'ai un peu de mal avec le concept.

      Posté par (page perso) . Évalué à 3.

      il y a un compilateur dans l'api. Si j'ai bien compris, il accepte trois types d'entrées differentes: soit du code source (clCreateProgramWithSource) , soit du bytecode, soit du code déjà compilé pour une liste de cibles spécifiques (clCreateProgramWithBinary)
    • [^] # Re: J'ai un peu de mal avec le concept.

      Posté par . Évalué à 8.

      L'implémentation d'Apple est basé sur llvm et ressemble beaucoup au fonctionnement de la pile OpenGL d'OS X 10.5.
      Le code OpenGL (et OpenCL) est compilé en bytecode llvm qui à l'exécution est optimisé puis mouliné dans un runtime JIT. En fonction du matériel présent, soit le code est directement exécuté sur le GPU soit par la CPU si la fonction OpenGL n'est pas disponible (typiquement avec les GPU intégré).
      Quelle est la différence avec les solutions précédentes, c'est que le runtime JIT basé sur llvm est plus performant que les interpréteurs classiques des pilotes OpenGL. Et pour Apple, ça leur évite de maintenir un interpréteur pour chaque plateformes (x86, PPC, ARM) et un gain de performance graphique (l'affichage dans OS X étant entièrement basé sur OpenGL).

      Voici une présentation qui explique très bien le fonctionnement de la pile OpenGL de OS X.
      http://llvm.org/devmtg/2007-05/10-Lattner-OpenGL.pdf

      Le runtime OpenCL déterminera quelle unité de calcul fournira les meilleures performances pour un calcul donné puis compilera/optimisera à la volée le bytecode pour celle-ci.



      PS: Grand Central ne se limiterait pas seulement au GPGPU (voire ne l'inclurait pas du tout), son but premier est de faciliter la programmation parrallèle (donc assez proche de Intel TBB ou Qt Concurrent).
      L'annonce de "Snow Leopard" va d'ailleurs dans ce sens.
      http://www.apple.com/pr/library/2008/06/09snowleopard.html

      À son habitude, Apple reste assez opaque à ce sujet, ce qui se cache derrière Grand Central est relativement vague, on n'est même pas sûr que Grand Central couvre le domaine du GPGPU. La page relative à Snow Leopard les traite comme deux technologies différentes (Grand Central = "multicore", OpenCL = "an another powerful Snow Leopard technology")
      http://www.apple.com/macosx/snowleopard/
  • # Ce n'est pas limité au GPGPU

    Posté par . Évalué à 9.

    Un petit copié coller de ce que l'on trouve dans la définition d'OpenCL :

    OpenCL (Open Computing Language) is the first open, royalty-free standard for general-purpose parallel programming of heterogeneous systems. OpenCL provides a uniform programming environment for software developers to write efficient, portable code for high-performance compute servers, desktop computer systems and handheld devices using a diverse mix of multi-core CPUs, GPUs, Cell-type architectures and other parallel processors such as DSPs.

    http://www.khronos.org/opencl/
    • [^] # Re: Ce n'est pas limité au GPGPU

      Posté par (page perso) . Évalué à 2.

      Merci pour le bout de gras ^^
      Un linux sous playstation 3 aurait beaucoup à gagner avec des programmes utilisant OpenCL, et ça serait plus intéressant pour les devs d'intégrer ce standard plutôt que de développer des versions uniquement Cell.
  • # nVidia supporte également OpenCL

    Posté par . Évalué à 10.

    L'affirmation qu'OpenCL est uniquement soutenu par les concurrents de nVidia est fausse et déplacée. nVidia a participé aux travaux pour rédiger la norme et compte supporter OpenCL sur ses GPUs. Le support d'OpenCL sera également inclus dans CUDA.
    Par ailleurs le président du groupe de travail d'OpenCL Neil Trevett est un des vice-président de nVidia.

    http://news.prnewswire.com/ViewContent.aspx?ACCT=109&STO(...)
    http://www.engadget.com/2008/12/09/nvidia-dishes-about-openc(...)


    > il m'a été impossible de trouver une quelconque licence ou de quelconques démos
    Les specs contiennent des exemples de codes, le comité n'est pas obligé de fournir une implémentation officielle, le document devant lui-même servir à guider les implémenteurs.
  • # hum...

    Posté par (page perso) . Évalué à 3.

    's/General Purpose Computing/General-Purpose Processing/'
  • # Malware

    Posté par . Évalué à 3.

    Toutes ces technologies apportent de nouvelles opportinités sympathiques. Intéressante présentation http://www.ruxcon.org.au/files/2008/reynaud_slides.pdf
    • [^] # Re: Malware

      Posté par (page perso) . Évalué à 2.

      Intéressante présentation

      Bof, je n'ai pas vu un seul exemple technique, ni une seule justification qui montrerait qu'on peut faire des malwares sur GPU. Je ne dis pas que c'est impossible, mais je voudrais bien voir un exemple ; en l'état ça ressemble à un gros FUD.
      • [^] # Re: Malware

        Posté par (page perso) . Évalué à 1.

        La complexité de l'architecture rendant les malwares plus difficilement détectables ?
        • [^] # Re: Malware

          Posté par (page perso) . Évalué à 3.

          Fais attention, tu sombres dans le même travers :) Je demande un exemple technique, une raison, même juste une théorie de fonctionnement d'un tel malware.

          Là dans les slides on a :
          - une partie où il dit qu'il ne sait pas trop comment fonctionne le GPGPU avec des visions haut niveau, et des distinctions d'APIs qui n'entrent pas en jeu pour ce qu'il veut faire
          - une partie avec des bouts de malwares pour x86 donc non pertinent pour ce qui nous intéresse
          - une partie sur la retro ingenierie qu'il n'a pas faite (aucun détail sur le fonctionnement de la protection mémoire sur GPU, par exemple qui pourrait expliquer qu'on puisse faire des malware)
          - une partie sur le packing, encore une fois avec les principes de fonctionnement x86, et aucune idée sur comment le faire marcher sur GPU
          - une conclusion qui met du FUD en rouge

          Bref, à mon avis c'est un concentré de poudre aux yeux. (J'espère que l'auteur de passe pas par ici, sinon il va me détester :)
          • [^] # Re: Malware

            Posté par . Évalué à 4.

            "Je demande un exemple technique"

            Par exemple, l'absence du support de debuger par les GPU pour analyser le comportement d'un code. La solution de debug actuelle fournie par NVidia se fait en ajoutant des flags dans le code, donc il faut le code source pour l'étudier dans ce mode. Bref mauvais présage pour certains types de détection utilisés par les antivirus.
            • [^] # Re: Malware

              Posté par (page perso) . Évalué à 4.

              Et ça veut dire qu'on peut faire des malware parce que ? Je ne vois pas le lien de cause à effet.

              Si tu me disais par exemple comment outrepasser la protection mémoire pour ajouter du code maison dans un shader, d'accord. Je connais assez bien les GPUs, n'hésite pas à être très technique dans cette description. En passant la modification de shaders requiert une intervention du CPU sur les puces nvidia et ATI, donc déjà un hypothétique malware aurait besoin de tourner sur le CPU. Du coup là on ne parle plus d'un malware GPU...

              En fait il n'y a pas aujourd'hui de façon de mettre des malware sur GPU. Par contre il y a des failles au niveau du driver, et ce dans la plupart des drivers à mon avis.

              La tentation de crier au loup a toujours été forte sur internet où tout le monde veut s'exprimer sans maîtriser les sujets, le faire c'est facile et vendeur... Mais en l'occurence baser un tel raisonnement sur de vagues impressions sur le debugging c'est du fud.
              • [^] # Re: Malware

                Posté par (page perso) . Évalué à 2.

                > Et ça veut dire qu'on peut faire des malware parce que ? Je ne vois pas le lien de cause à effet.

                ça veut dire que les auteurs de malwares, et les auteurs de solutions de protection pourraient effectivement s'y interesser si ça permet de faire tourner certains bouts de code "sensible" dessus. Comme il n'y a pas (encore) d'outils de reverse engineering c'est forcement assez tentant comme solution d'obfuscation
                • [^] # Re: Malware

                  Posté par (page perso) . Évalué à 9.

                  Bonjour,

                  Je suis l'auteur de la présentation dont il est question donc je pense que je peux répondre à certaines questions qui ont été soulevées.


                  > Je demande un exemple technique, une raison, même juste une théorie de fonctionnement d'un tel malware.

                  Pas de problème. On ne peut pas exécuter de code directement sur le GPU, il faut que le code en question soit contenu dans un binaire classique pour la plate-forme cible. Quand on lance le binaire, on a donc:

                  - un programme H qui tourne sur le CPU (la partie Hote)
                  - un programme D qui tourne sur le GPU (la partie Device)
                  - un canal de communication entre les deux (via l'API de CUDA/OpenCL/Larrabee/n'importe)

                  Donc au lieu d'avoir un programme classique P sur CPU, on a deux programmes sur deux processeurs qui communiquent. On ne peut pas en faire plus ni moins qu'avant, mais si on peut programmer P pour être un malware, on peut aussi le faire avec H et D.

                  Ce qui a pu provoquer une confusion, c'est que je ne m'intéresse ensuite qu'à la partie D mais elle ne peut évidemment pas s'exécuter toute seule, elle a besoin de H pour pouvoir se lancer.

                  D'autre part, D ne peut pas faire d'appels système directement, il ne peut que demander à H de les faire pour lui. Donc c'est forcément H qui va exécuter la charge finale du malware (ouverture de sockets, vols de cookies, de mots de passe...). D'une certaine manière, le malware c'est juste H, mais c'est un H qui communique avec un truc, et ce truc m'intéresse.


                  > une partie avec des bouts de malwares pour x86 donc non pertinent pour ce qui nous intéresse

                  ce que je dis dans cette partie, c'est que ce bout de code x86 aurait été beaucoup plus difficile à analyser s'il avait été compilé pour le GPU.


                  > une partie sur la retro ingenierie qu'il n'a pas faite (aucun détail sur le fonctionnement de la protection mémoire sur GPU, par exemple qui pourrait expliquer qu'on puisse faire des malware)

                  on n'a pas besoin de savoir comment marche la protection mémoire sur GPU pour faire du reverse. Ce qu'on doit savoir, c'est comment désassembler le code, le débugger et l'émuler.


                  > une partie sur le packing, encore une fois avec les principes de fonctionnement x86, et aucune idée sur comment le faire marcher sur GPU

                  j'essaie de voir si on peut appliquer le packing à la x86 au code sur GPU. La réponse est: "la vache c'est pas gagné, le plus simple est encore de coder sa propre machine virtuelle sur le GPU".
                  • [^] # Re: Malware

                    Posté par (page perso) . Évalué à 3.

                    « un programme H qui tourne sur le CPU (la partie Hote) ... D'autre part, D ne peut pas faire d'appels système directement »

                    Hum, dans ce cas la partie H est un virus classique et je pense qu'il sera facile à identifier. Bref, rien d'intéressant ici. Je trouve les malwares utilisant la virtualisation plus rigolos.

                    De toute manière, les pirates développent rarement des malwares très intelligents. La plupart du temps, ils réutilisent des vieux virus et rajoutent des failles connues et déjà patchées. Mais ça fonctionne car sous Windows il est difficile d'avoir un OS 100% à jour (lire le rapport Secunia récent à ce sujet). Je veux dire qu'ils s'amusent pas à développer des solutions très pointues car :
                    - il a peu de développeurs capables de le faire (main d'œuvre chère)
                    - c'est moins fiable que du code courant (répandu et mieux testé)

                    Bien sûr, en théorie le virus ultime est très effrayant car il serait totalement indétectable et pourrait mettre le Terre à feu et à sang (revoir Die Hard 4 avec Bruce Willis, Matrix, etc.). Bon, dépêchez vous de troller car le LHC va bientôt être (re)mis en marche, faites gaffe de pas mettre les pieds dans un trou noir.
                    • [^] # Re: Malware

                      Posté par (page perso) . Évalué à 4.

                      > Hum, dans ce cas la partie H est un virus classique et je pense qu'il sera facile à identifier.

                      Non pas forcément. H peut très bien être un interpréteur de commandes genre bash, et D peut être un programme dont la sortie est une liste de commandes. L'analyse de H ne révèle rien sur le comportement de H+D.


                      > De toute manière, les pirates développent rarement des malwares très intelligents.

                      C'est vrai mais on en trouve quand même de temps en temps des biens faits, genre Rustock.C. Dans tous les cas, c'est mon job de les étudier :)


                      > en théorie le virus ultime est très effrayant car il serait totalement indétectable

                      un virus totalement indétectable n'existe pas
                      • [^] # Re: Malware

                        Posté par (page perso) . Évalué à 2.

                        Non pas forcément. H peut très bien être un interpréteur de commandes genre bash

                        Tu aurais un exemple de commande bash pour utiliser ton GPU ? Parce que là je suis très curieux de savoir comment on fait. Justement, je voulais dire qu'un programme qui utilise intensivement le GPU est détectable de par son comportement.
                  • [^] # Re: Malware

                    Posté par (page perso) . Évalué à 1.

                    ce que je dis dans cette partie, c'est que ce bout de code x86 aurait été beaucoup plus difficile à analyser s'il avait été compilé pour le GPU.

                    Ok, je commence a comprendre ce que tu veux faire. Cependant, je ne partage toujours pas ton point de vue. Par exemple, pourquoi les slides disent qu'on ne sait pas analyser le PTX ? Je te renvoie vers deux projets qui savent desassembler des shaders/cuda nv50 :
                    http://www.cs.rug.nl/~wladimir/decuda/
                    http://nouveau.freedesktop.org/
                    Ces 2 projets datent de 2007 et 2005 respectivement, donc sont antérieurs aux slides qui disent 2008.

                    Du coup, je ne pense pas que le code cuda soit difficile à comprendre, il suffit de lancer les utilitaires et de lire l'assembleur. Comme pour x86 en fait...
                    • [^] # Re: Malware

                      Posté par (page perso) . Évalué à 2.

                      > pourquoi les slides disent qu'on ne sait pas analyser le PTX ?

                      je ne l'ai pas mentionné dans les slides mais le bout de code PTX que je montre a été obtenu avec decuda justement. Le problème c'est qu'il s'agit d'un programme non officiel et virtuellement non maintenu. Au passage on peut noter l'effort héroïque de l'auteur qui s'est cogné le reverse d'un format propriétaire non documenté...


                      > il suffit de lancer les utilitaires et de lire l'assembleur

                      c'est un peu la seule option qui reste pour analyser le code en effet. Mais s'il est packé, on l'a dans l'os.
  • # Microsoft

    Posté par (page perso) . Évalué à 8.

    Cependant, un grand nombre d'acteurs se sont joints au projet et aujourd'hui on trouve, entre autres : Apple, AMD, NVIDIA, Intel, Broadcom, Blizzard, EA, Ericsson, IBM, Movidia, Nokia, Sony, Symbian, Texas Instruments.

    ...mais pas Microsoft...
    Ils ont un projet similaire dans leur botte ou ils n'ont pas vu le truc venir?
    • [^] # Re: Microsoft

      Posté par (page perso) . Évalué à 10.

      Le prochain Windows Seven contiendra DirectX 11. Ce dernier proposera les "compute shaders" qui jouent un rôle similaire à OpenCL et on va donc , une fois de plus, avoir une quasi-norme soutenue par toute le monde sauf Microsoft (à-la-OpenGL) et une techno pure Microsoft.
      Fais chier.
      • [^] # Re: Microsoft

        Posté par . Évalué à 3.

        s/fait chier/Microsoft continue a faire chier/ mais ca on en a l'habitude.

        De tout de facon vu la croissance des OS concurrents, remercions d'ailleurs les devs microsofts a Redmond pour leur "fabuleux" Vista, cela n'est pas trop trop grave. Vu comment c'est dans les universites actuellement il y aura plus d'Unix dans 10 ans que de Windows dans les entreprises. La majorite des ordinateurs achete par les etudiants etant des macs. Du coup OpenCL a probablement de tres beaux jours devant lui.
        • [^] # Re: Microsoft

          Posté par (page perso) . Évalué à 10.

          La majorite des ordinateurs achete par les etudiants etant des macs.(référence nécessaire)

          C'est bizarre, dans les établissement que je côtoie, si dans des sections bien spécifiques cette affirmation peut être vraie (et encore), de manière globale, il y a *bien plus* de PC dans les amphis que de macs... (de l'ordre de 9/10). Et sur ces 9 PC, je dirais qu'en gros 8 utilisent l'OS de redmond. Dans les filières orientée informatique, ce chiffre tendra peut être vers 6 au mieux...

          Bon, après, je ne considère pas que ces quelques établissements sont représentatif des achats informatique par les étudiants Français, mais bon... de là à avoir plus de Mac que de PC dans les cycles supérieurs... y'a une différence que je ne m'explique pas entre ton propos et ma vision.
          • [^] # Re: Microsoft

            Posté par . Évalué à 5.

            Je ne suis pas en France et je frequente plutot les facs nord americaines. Il se trouve que ici ce sont les macs qui dominent et le truc le plus rigolo c'est que c'est surtout vrai dans les cursus non scientifique. Il faut dire qu'ils ont generalement moins besoins de logiciels particuliers en a partir du moment ou ils ont Office, photoshop et de quoi voir leur dvd ils sont content. Les raisons pour le choix macs sont par contre assez subjective puisque souvent c'est "Ils sont cool" ou "Ils sont beaux" et oui ce genre de details fait encore vendre. Il faut bien avouer que les portables pc sont dans l'ensemble beaucoup plus moche ou beaucoup moins bien fini.
            • [^] # Re: Microsoft

              Posté par (page perso) . Évalué à 4.

              Désolé d'avoir préjugé du lieu où tu avais cette vision ;-) je suis trop franco-centré.

              Par ici aussi, (France donc), je vois beaucoup de macs dans les filières type "communication", "journalisme" ou "architecture", "graphisme" et peu sur les bancs des sections "techno". Les raisons sont souvent du même acabit (look, tendance, finitions...) mais l'argument financier est encore le point faible de ces machines.
              • [^] # Re: Microsoft

                Posté par . Évalué à 7.

                Ah moi de mon côté c'était « les macs c'est génial, c'est linux avec MS office ». Quand je leur signalais qu'il n'y avait pas une ligne de linux dans Mac je passais pour un chieur qui pinaillait sur des détails. Le second argument c'était effectivement « oui mais c'est joli ». Sauf que d'une je ne trouve pas l'esthétique des macs meilleure que ça et c'est de toute façon le dernier critère que j'utilise pour choisir un ordinateur. Et pour couronner le tout je voyais toute leur incompréhesion lorsque je leur faisais comprendre qu'utiliser un OS propriétaire (parce que oui, mettre linux aurait été un sacrilège) allait contre mes principes.

                Après au niveau de l'évolution du rapport de force mac/linux dans mon laboratoire de thèse il faut être réaliste : mac a exterminé linux. À la fin il ne restait plus grand monde à utiliser linux et la plupart de ceux qui avaient commencé sous linux avaient fini par passer sous mac. Dans mon laboratoire (nord-américain) de post-doc pour simplifier les post-docs (sauf moi) et les chercheurs en poste sont sous mac, les étudiants sont sous linux (et encore quelques uns sont passés sous mac). J'ai l'impression de voir la même évolution que dans mon ancien labo. Au final je pense que le pire ennemi de linux dans mon domaine ce n'est pas windows (de toute façon certains logiciels dont on a besoin ne tournent pas sous windows) mais mac.

                Concernant les raisons de la désaffection, cela n'engage que moi et c'est très subjectif. Je pense que les linux installés sur les machines des labos sont _nuls_. Ce sont des versions archaïques bourrées de bugs, souvent mal configurées, ne savent pas monter un disque dur externe correctement, etc. Du coup j'ai entendu bien des fois « Pffff linux c'est super nul, ça ne sait même pas faire [insérer ici une fonctionalité marchant parfaitement avec toute distribution semi-récente]. » Sans compter les choses qui marchent mal pour cause de protocole fermé/logiciel proprio. J'ai beau leur expliquer que les distribs linux n'y peuvent rien, ça ne les intéresse pas. Elles veulent que ça marche. D'un autre côté comme les macs sont sans support des admins, ou sans support centralisé du moins, les utilisateurs de macs ont moins de contraintes, ils peuvent installer ce qu'ils veulent sans attendre le bon vouloir de l'admin qui met 3 semaines à installer le logiciel dont ils ont besoin dans les 5 minutes, etc. Et comme ils sont persuadés que linux c'est trop compliqué de toute façon (la preuve il y a un admin rien que pour ça et même avec lui rien ne marche jamais) …

                Bref il faudra bien des années pour inverser la tendance. Il faudra que linux paraisse cool. Que linux soit vendu sur des machines prétenduement jolies. Que les admins mettent des versions qui fonctionnent (tout simplement). Juste pour préciser je travaille dans les sciences dures.
        • [^] # Re: Microsoft

          Posté par . Évalué à 7.

          il y a 10 ans j'entendais la même chose. Comment windows était amené à disparaitre aprés le bug de l'an 2000.

          C'etait des analyses faites par des personnes/des groupes "trés sérieux", qui prenaient la marge de progression la plus basse etc.

          Je me garderais bien maintenant de jouer madame Soleil. Les technologies de Redmond sont discutables, mais leur adoption est malgré tout généralement massive (plateforme .net, silverlight, sharepoint).
  • # Khronos Group

    Posté par . Évalué à 6.

    ça me fait un peu peur qu'on laisse le Khronos Group gérer l'affaire. Vu ce qu'ils ont fait pour OpenGL 3...
    • [^] # Re: Khronos Group

      Posté par . Évalué à 1.

      qu'est-ce que tu reproche à OpenGL 3?
      • [^] # Re: Khronos Group

        Posté par . Évalué à 7.

        Le retard pris par la norme?
        • [^] # Re: Khronos Group

          Posté par . Évalué à 4.

          La capacité à prendre le temps de réfléchir pour proposer une base saine sans pour autant mettre au rebus les centaines d'applis qui en dépendent plutôt que de sortir une nouvelle itération pour faire monter la version ?

          A titre de comparaison, il y a eu 24 mois entre la 2.1 et la 3.0 et 27 mois entre DirectX 9.0c et 10.
          • [^] # Re: Khronos Group

            Posté par . Évalué à 5.

            je ne dis pas le contraire mais il a ete demande ce qui pouvait etre reproche a Kronos. De plus la principale critique que j'ai pu voir ce n'etait pas de faire attention que OpenGL 3.0 soit une bonne norme, ceci est tout a leur honneur, le probleme c'est que pendant plus d'un ans il n'y a eu aucun message et que a peu pres personne ne savait la raison du retard.
            • [^] # Re: Khronos Group

              Posté par . Évalué à 2.

              Je sais pas si c'est le fait du Khronos Group, mais OpenGL 3 nous promettait Monts et Merveilles, enfin une alternative crédible a DirectX. Au final, c'est juste une nième version de plus. Faudrait que je retrouve l'intervention de Carmack, qui résumait bien les choses je trouve.
  • # kthxbye

    Posté par . Évalué à 7.

    Cependant, un grand nombre d'acteurs se sont joints au projet et aujourd'hui on trouve, entre autres : Apple, AMD, NVIDIA ... fin d'éviter que CUDA (la technologie propriétaire qui est soutenue par NVidia) ne s'empare totalement de ce nouveau marché, les autres acteurs se sont regroupés derrière la bannière d'OpenCL...

    C'est la première fois qu'une note additionnelle sensée expliciter les choses provoque chez moi l'effet inverse.
    • [^] # Re: kthxbye

      Posté par (page perso) . Évalué à 4.

      Elle est juste fausse, c'est tout ;)

      En gros, nvidia a dégainé le premier en proposant CUDA qui permet de faire du gpgpu sur les gpu nvidia.
      Puis AMD/ATI a sorti sa version nommée "stream computing".
      Puis Apple a fait son framework et a réussi à unifier tout le monde (y compris nvidia) sauf Microsoft (qui préfère direct3D (je ne suis pas sur que ce soit équivalent cependant)).
      • [^] # Re: kthxbye

        Posté par (page perso) . Évalué à 2.

        NVidia participe à OpenCL mais n'a absolument pas annoncé qu'il allait abandonner CUDA au profit d'OpenCL.
        Actuellement DirectX 11 (et ses "compute shaders") n'est pas sorti et le leader unique du marché c'est CUDA donc il est clair que OpenCL attaque la suprématie de CUDA.
        • [^] # Re: kthxbye

          Posté par (page perso) . Évalué à 7.

          nvidia est exactement dans la même situation qu'AMD : ils ont chacun leur propre bibliothèque et compilateur pour faire du GPGPU. Ils fournissent tous les deux des chips à Apple qui veut faire du GPGPU une feature de la prochaine version de son SE. Ils se raccrochent tous les deux à ce qui va devenir le standard. Apple est la force qui a mis openCL en branle, mais pas plus contre nvidia et cuda que contre amd et stream computing, juste contre des implémentations totalement incompatibles et opaques.
        • [^] # Re: kthxbye

          Posté par . Évalué à 5.

          On est à la limite de la mauvaise foi.

          Faut arrêter de pinailler, nVidia a annoncé le support complet d'OpenCL dans CUDA et ils se sont particulièrement investi dans l'élaboration de celle-ci.
          nVidia ne peut pas abandonner du jour au lendemain CUDA (*), en revanche, il est clair que dans le futur CUDA = OpenCL (+DX11) + extensions propriétaires. CUDA deviendra progressivement une implémentation spécifique d'OpenCL et non plus une API indépendante comme aujourd'hui.
          ça ne vous rappelle pas un autre standard dirigé par le Khronos Group ?
          Pardi, OpenGL ! Après, la question est de savoir si nVidia (et les autres constructeurs) feront intégrer leurs extensions dans les prochaines révisions d'OpenCL comme ils le font avec OpenGL.

          Annonce de nVidia à propos d'OpenCL:
          http://www.nvidia.com/object/io_1228825271885.html


          Par ailleurs, AMD s'oriente dans la même direction que nVidia, Stream SDK évoluera pour supporter OpenCL (et DX11) mais ils maintiendront également leur API et langage propriétaire Brook+ (basé sur le framework libre BrookGPU).
          http://www.amd.com/us-en/Corporate/VirtualPressRoom/0,,51_10(...)

          > le leader unique du marché c'est CUDA
          Certes, mais le marché n'est qu'à ses débuts et est très fragmenté, l'arrivée d'un framework "multiplateforme" (**) comme OpenCL peut encore changer la donne.
          La véritable bataille commencera avec DX11, c'est d'ailleurs la raison pour laquelle tout les acteurs majeurs à l'exception de M$ se sont ralliés à OpenCL (sans pour autant négliger DX11 pour les fabricants).



          (*) quid des clients, des programmes déjà développés et des développeurs qui ont été formés ? CUDA n'a que 2 ans, trop tôt pour abandonner le support.
          (**) c-a-d supportant une vaste gamme de GPUs et non pas "multi-OS".
      • [^] # Re: kthxbye

        Posté par (page perso) . Évalué à 2.

        Elle est juste fausse, c'est tout ;)

        Ou faussement juste...
  • # un pon projet pour un portage ves openCL

    Posté par . Évalué à 1.

    c'est en regardant les lauréats potentiels des trophes du libre 2009 que j'ai trouvé ca, cet un solveur lineaire ecrit en C++ et GUDA disponible,en GPL, sur le site des autheurs de graphite et openML.
    ca pourait servir pour la bibliotheque DLAS de gnu
    http://fr.wikipedia.org/wiki/Basic_Linear_Algebra_Subprogram(...)
    http://alice.loria.fr/publications/papers/2008/CNC/Buatois_e(...)

    http://alice.loria.fr/index.php/software/4-library/34-concur(...)

    bon j'ai assez fait de pub la :)

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.