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.
Aller plus loin
- Version 1.0 d'OpenCL (48 clics)
- Sur wikipedia (25 clics)
- Sur le site du Khronos Group (20 clics)
# Benchmark
Posté par FRLinux (site web personnel) . Évalué à 5.
[^] # Re: Benchmark
Posté par mirak mirak . Évalué à -1.
et qui affichent les vidéos sans déchirement
[^] # Re: Benchmark
Posté par ethtezahl . Évalué à -1.
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 mirak mirak . Évalué à 3.
et sur le driver libre je leur jette pas la pierre
elle est réservée à ATI
un beau granit
# licence
Posté par Efemero (site web personnel) . Évalué à 9.
/*******************************************************************************
* 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 Frédéric COIFFIER . Évalué à 2.
/*
* 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 ZeroHeure (site web personnel) . Évalué à 4.
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 fleny68 . Évalué à 7.
Bref ça marche comment?
[^] # Re: J'ai un peu de mal avec le concept.
Posté par Maclag . Évalué à 7.
- 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 Troy McClure (site web personnel) . Évalué à 3.
[^] # Re: J'ai un peu de mal avec le concept.
Posté par GeneralZod . Évalué à 8.
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 Geo Vah . Évalué à 9.
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 Az' (site web personnel) . Évalué à 2.
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 GeneralZod . Évalué à 10.
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 s[e]th & h[o]lth (site web personnel) . Évalué à 3.
# Malware
Posté par suJeSelS . Évalué à 3.
[^] # Re: Malware
Posté par Stephane Marchesin (site web personnel) . Évalué à 2.
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 Nÿco (site web personnel) . Évalué à 1.
[^] # Re: Malware
Posté par Stephane Marchesin (site web personnel) . Évalué à 3.
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 suJeSelS . Évalué à 4.
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 Stephane Marchesin (site web personnel) . Évalué à 4.
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 Troy McClure (site web personnel) . Évalué à 2.
ç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 reynaudd . Évalué à 9.
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 Victor STINNER (site web personnel) . Évalué à 3.
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 reynaudd . Évalué à 4.
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 Victor STINNER (site web personnel) . Évalué à 2.
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 Stephane Marchesin (site web personnel) . Évalué à 1.
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 reynaudd . Évalué à 2.
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 bob le homard . Évalué à 8.
...mais pas Microsoft...
Ils ont un projet similaire dans leur botte ou ils n'ont pas vu le truc venir?
[^] # Re: Microsoft
Posté par patrick_g (site web personnel) . Évalué à 10.
Fais chier.
[^] # Re: Microsoft
Posté par abramov_MS . Évalué à 3.
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 pampryl . Évalué à 10.
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 abramov_MS . Évalué à 5.
[^] # Re: Microsoft
Posté par pampryl . Évalué à 4.
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 med . Évalué à 7.
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 Graveen . Évalué à 7.
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 zakMcKraken . Évalué à 6.
[^] # Re: Khronos Group
Posté par ecyrbe . Évalué à 1.
[^] # Re: Khronos Group
Posté par abramov_MS . Évalué à 7.
[^] # Re: Khronos Group
Posté par Jean Roc Morreale . Évalué à 4.
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 abramov_MS . Évalué à 5.
[^] # Re: Khronos Group
Posté par zakMcKraken . Évalué à 2.
# kthxbye
Posté par sciopath . Évalué à 7.
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 태 (site web personnel) . Évalué à 4.
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 patrick_g (site web personnel) . Évalué à 2.
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 태 (site web personnel) . Évalué à 7.
[^] # Re: kthxbye
Posté par GeneralZod . Évalué à 5.
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 Thierry Thomas (site web personnel, Mastodon) . Évalué à 2.
Ou faussement juste...
# un pon projet pour un portage ves openCL
Posté par cedric . Évalué à 1.
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.