CUDA 4.0 arrive, la release candidate disponible

La sortie cette semaine aux développeurs enregistrés de CUDA est l’accomplissement de milliers d’heures dédiées à ce projet. Cette technologie peut sembler jeune, sa première version, la 1.0, n’a été sortie qu’en 2007. L’effet de cette sortie sur le monde entier n’a, sans nul doute possible, pas été nul. Elle n’est pas non plus le seul terrain d’avance pour les technologies massivement parallèles sur matériel NVIDIA : les API comme OpenCL et DirectCompute sont elles aussi supportées et améliorées, en plus d’un accès direct au GPU en C, C++ et Fortran.

Comme toujours, NVIDIA est à la recherche d’aide sur le sujet, notamment au niveau des retours d’utilisateurs, d’améliorations possibles, des bogues ; tout ce qui vous empêche de développer rapidement, de déployer des applications sans souci, tout cela doit être amélioré. Si vous êtes intéressé dans cette perspective, n’hésitez pas à vous enregistrer comme développeur.

Le contenu de CUDA 4.0

Venons-en au fait de cette sortie prochaine, vendredi 4 mars aux développeurs enregistrés.

Notons la version 2.0 de GPUDirect, une technologie qui offre un support pour des communications entre les GPU d’un serveur ou d’une station de travail, une fonctionnalité que beaucoup décrivent comme un outil pour un développement plus rapide et plus aisé pour plusieurs GPU, ainsi qu’un vecteur d’améliorations de performances.


UVA, acronyme de Unified Virtual Addressing, permet d’utiliser un espace d’adressage mémoire unifié entre la mémoire du système et celles des GPU.

Aussi, grande nouveauté par rapport aux versions précédentes de CUDA, le partage entre divers threads de GPU : plusieurs threads ou processus sur le CPU peuvent utiliser le même GPU pour leurs calculs. De même, un même thread CPU peut utiliser plusieurs GPU en même temps. Thrust est désormais intégré dans CUDA, le portage de la STL du C++ aux technologies du GPU.

Pour les amateurs de C++, de nouvelles fonctionnalités propres au langage sont désormais supportées, comme les fonctions virtuelles, ainsi que les mots clés new et delete pour la gestion de la mémoire allouée.

Sources : http://blogs.nvidia.com/2011/03/announcing-cuda-4-0/, http://developer.nvidia.com/object/cuda_4_0_RC_downloads.html, http://www.ddj.com/high-performance-computing/229219474;jsessionid=YAXVYSIIVLYCTQE1GHPSKH4ATMY32JVN, http://www.anandtech.com/show/4198/nvidia-announces-cuda-40 (d’où proviennent les images)

Advertisements

PySide 1.0.0 beta 2, le support complet des interfaces déclaratives arrive dans ce bindind LGPL Python de Qt

Voici donc sortie la deuxième beta de PySide, le binding Python de Qt initié par Nokia, dont la principale différence avec le binding historique, PyQt, réside dans la licence : PySide est disponible sous LGPL, une licence moins restrictive que la GPL employée par PyQt. Ainsi, un binding Python de Qt peut être utilisé pour des développements propriétaires sans obligation de payer une licence commerciale.

La première version beta de PySide (la bien dénommée beta 1) apportait un grand changement par rapport aux versions précédents (0.4.2 et avant) : un changement dans l’ABI (Application Binary Interface), ce qui, pour rester en dehors des détails techniques, obligeait à recompiler toute application se basant sur PySide (notamment le module Python). Cependant, ainsi, le projet se dote d’une architecture qui pourra servir pendant encore un certain temps, enlevant les choix de conceptions qui se sont avérés moins bons que d’autres.

La beta 1 améliorait le support de Qt Quick et de QML, les interfaces utilisateur dans ce langage déclaratif étaient désormais possibles en Python ; une seule chose manquait : l’enregistrement de nouveaux types QML depuis Python. Cela est désormais possible, comme l’atteste l’exemple : http://qt.gitorious.org/pyside/pyside-examples/trees/master/examples/declarative/extending/chapter5-listproperties.

Le support de Python 3 a été déclaré comme “non insurmontable” mais est prévu pour après la sortie de la version finale de la branche 1.0. Il est à remarquer, à ce niveau, que PyQt supporte déjà Python 2.x et 3.x, mais propose à chacun des API différentes, l’API 1 est plus prévue pour le portage d’applications du C++ au Python (par défaut pour Python 2.x), l’API 2 étant plus pythonique (par défaut pour Python 3.x), ce qui n’est pas très cohérent. Le PSEP 101, déjà implémenté, fait le choix de ne se baser que sur l’API 2, car plus pythonique ; ce choix permettra de passer sans trop de dégâts dans son code à Python 3.x.

Afin de fignoler le travail, au moins deux betas sont prévues avant cette version finale (trois semaines avant la beta 3, puis deux semaines pour la beta 4 et deux nouvelles semaines pour la finale, tels sont les projets).

Canonical et Nokia pourraient travailler en collaboration sur Qt

Sur les quelques derniers mois, des contacts ont eu lieu entre les développeurs de Qt et Canonical ainsi qu’avec les participants au projet Ubuntu. Mark Zimmerman, CTO de Canonical, disait sur son blog, en octobre :

I have been thinking about Qt recently. We want to make it fast, easy and painless to develop applications for Ubuntu, and Qt is an option worth exploring for application developers. In thinking about this, I’ve realized that there is quite a bit of commonality between the strengths of Qt and some of the new directions in Ubuntu.

Overall, I think Qt has a lot to offer people who want to develop applications for (and on) Ubuntu, particularly now. It already powers popular cross-platform applications like VLC, not to mention the entire Kubuntu distribution. I missed it when this happened last year, but Qt is now available under either the LGPL 2.1 or the GPL 3.0, which should make it suitable for virtually any Ubuntu application. It has strong commercial backing as well as a large developer community.

J’ai pensé à Qt récemment. Nous voulons que le développement d’applications pour Ubuntu soit rapide, simple, sans anicroche, Qt est une option qui mérite d’être explorée pour les développeurs. En pensant à tout cela, j’ai trouvé qu’il y avait quelques points communs entre les forces de Qt et les nouvelles orientations d’Ubuntu.

En général, je pense que Qt a beaucoup à offrir à des gens qui veulent développer pour (et sur) Ubuntu, particulièrement maintenant. Il est déjà à l’œuvre dans des applications multiplateformes comme VLC, sans oublier la distribution Kubuntu dans son entièrement. Je ne l’avais pas remarqué l’année dernière, Qt est maintenant disponible en LGPL 2.1 ou GPL 3.0, ce qui le rend utilisable pour à peu près toute application Ubuntu. Il possède aussi un support commercial et une large communauté de développeurs.

Et de citer plusieurs points communs, dont les plateformes supportées. Qt supporte depuis longtemps ARM comme x86, depuis plus de dix ans ; Ubuntu supporte les produits basés sur ARM depuis deux ans, la dernière version supporte encore plus de processeurs ARM ; de son côté, Qt optimise son utilisation de ARMv7, la dernière version de l’architecture. Ainsi, on peut fournir aux fabricants un large choix de matériel sans sacrifier la gamme de logiciels disponibles.

Par la suite, deux développeurs de Qt, Zeno Albisser et Dennis Dzyubenko, ont été personnellement invités à la Ubuntu Developer Conference 2010, qui a eu lieu à Orlando. Ils avaient pour but d’aligner la stratégie de Canonical pour le support d’Ubuntu et des services liées avec Qt, ont participé à différentes discussions sur les gestes et les méthodes d’entrée multipoint. Bien évidemment, ils brandissaient le drapeau Qt ! Selon Zeno, Canonical est très intéressé par l’approche de Qt pour utiliser la puisse de l’entrée par des gestes (taper, taper et maintenir, balayer, etc.).

La vérité, cependant, est que rassembler deux communautés, deux flux de développement n’est jamais une mince affaire, même si les deux groupes sont de bonne disposition dès le tout début. Quand il s’agit d’en venir au niveau de la technologie, Zimmerman avait déjà suggéré que travailler ensemble pour activer le support des gestes d’une manière collaborative sera un processus assez complexe. Il disait même que Qt avait un système d’entrée tactile très mature, avec maintenant le support du multitouch et des gestes, dont QML (fairly mature touch input system, which now has support for multi-touch and gestures (including QML)), il est donc de ceux qui voudraient aligner les développements de la communauté Canonical vers les outils offerts par Qt. Cependant, ces fonctionnalités ne sont complètement implémentées et supportées que sous Windows 7 et Mac OS X 10.6, rien pour Linux et X11 pour le moment (bien qu’un développement d’un framework de bas niveau pour ces plateformes soit en cours de développement).

Du côté de Qt, l’objectif est de travailler dur, avec un peu de magie et de chance si nécessaire, pour aller plus loin dans la collaboration avec Canonical et Ubuntu, pour que tous partagent le même framework.

Mais est-ce une si bonne nouvelle ?

Sources : http://blog.qt.nokia.com/2010/12/22/my-new-years-resolution-plus-canonical-and-the-opportunity-to-work-more-closely/ et http://mdzlog.alcor.net/2010/10/20/ubuntu-and-qt/

Sortie de Qt Mobility 1.0.2 et d’une technology preview de Qt Mobility 1.1.0

La version 1.0.2, très mineure

La sortie de la version 1.0.2 de Qt Mobility a été beaucoup plus surveillée que celles de la 1.0.0 ou la 1.0.1, surtout suite au dernier accrochage. Les seules vraies corrections de cette version sont un crash de l’API de localisation sur Symbian, des échecs pour l’API des capteurs sur Maemo 5 ainsi que les corrections des autres problèmes détectés à la sortie de la version 1.0.1.

La Technology Preview de la 1.1.0

Mais la nouvelle la plus intéressante n’est pas cette nouvelle version, il s’agit de la technology preview de la version 1.1.0. Cette nouvelle version apportera son lot de nouvelles API. Suite au modèle de contribution actuel de Nokia, il s’agit de partager avec le public dès que possible les avancées futures du projet, afin que tous les utilisateurs puissent contribuer à l’évolution du framework, à tous les niveaux (rapports de bogues, demandes de fonctionnalités, fourniture d’un patch…), même si la qualité voulue de la branche 1.0 doit être atteinte. Notamment, les API ne sont pas encore parfaitement supportées sur toutes les plateformes : cela viendra, il est plus important de communiquer sur le futur du projet et ainsi assurer sa qualité. Surtout qu’il y a nettement moins de code à modifier en cas de changement dans l’API, il est donc plus facile de leur proposer des modifications à ce niveau. Vos contributions au code sont néanmoins toujours les bienvenues, surtout sur Symbian et Maemo ; plus tard cette année, dans le second semestre, vous n’entendrez plus parler de Maemo ici : l’environnement de développement principal passera à Meego !

Pour cette Technology Preview, le Qt Developer Network entre dans la danse. Notamment, toutes les API seront présentées sur le wiki, chacune aura droit à son forum pour les discussions spécifiques sur l’API, la laissant maturer jusqu’à la version beta puis finale.

Quel sera le contenu de cette 1.1.0 ?

Pas moins de huit nouvelles API sont prévues :

  1. Service Framework API (Out-of process) ;
  2. Document Gallery API ;
  3. Maps/Navigation API ;
  4. Organizer API ;
  5. Landmarks API ;
  6. Camera API ;
  7. Versit/Organizer API ;
  8. Telephony Events API ;
  9. Feedback API ;
  10. Contacts API.

Des sources sont d’ores et déjà disponibles.

Certaines API ont été plus travaillées que d’autres, elles sont cependant suffisamment avancées pour que vous puissiez commencer à les étudier. La majorité sont disponible sur Maemo 5, étant donné qu’il s’agit pour le moment de l’environnement de développement principal. Les fichiers SIS pour Symbian ne sont pas disponibles, le support de cette plateforme n’étant pas encore suffisamment avancé. Chaque API propose aussi une application d’exemple pour en montrer l’utilisation.

Sources : Qt Mobility 1.1.0 Technology Preview et Qt Mobility 1.0.2 Released.

Et vous ?

Utilisez-vous déjà ces API ? Ne sont-elles utiles que pour le développement sur mobiles ?
Avez-vous déjà testé cette version préliminaire ? Qu’en pensez-vous ?

Le voyage de Qt Web Runtime débute ici

Il y a peu, dès Qt 4.4 en réalité, Qt dispose de son wrapper autour de WebKit : Qt WebKit. Depuis, ce module est devenu l’un des plus utilisés de Qt ; en effet, utiliser du contenu Web est extrêmement demandé par le marché actuel. Dans les télévisions, les netbooks, les téléphones mobiles et bien d’autres périphériques domestiques, l’utilisation de l’Internet est absolument irremplaçable, l’application étant hébergée sur le Web. Il était donc temps de fournir une couche supplémentaire pour faciliter et sécuriser le développement d’applications basées sur le Web. D’où un nouveau projet pour les équipes de développement de Qt : [SIZE=”3″]le Qt Web Runtime[/SIZE], basé sur Qt et sur Qt WebKit, grâce auquel les applications Web deviendront plus facilement plus fonctionnelles.

L’un des objectifs de ce framework est de fournir un runtime Web basé sur les standards du W3C. Ainsi, vous pourrez facilement développer et déployer des applications Web sur des smartphones ou d’autres plateformes de la même manière qu’une application plus traditionnelle.

La fonctionnalité-clé ? Vous pouvez accéder au matériel (appareil photo ou accéléromètre, par exemple) et aux autres ressources de l’appareil (liste de contacts, messages…) [I]via[/I] des API JavaScript.

En code, voici ce que donne l’accès à l’accéléromètre du périphérique :

var wrtSensors = nokia.device.load("sensors");
wrtSensors.startChannel(callback, "AccelerometerAxis", errorCallback);

function callback(data) {
console.log("x-axis: " + data.axisX + " y-axis: " + data.axisY + " z-axis: " + data.axisZ);
}

function errorCallback(err) {
console.log("Ouch, " + err.message + "error code:" + err.code);
}

Il suffit de s’enregistrer aux notifications concernant l’accélération (soit le canal [I]AccelerometerAxis[/I]) grâce à la méthode [I]startChannel[/I]. Ensuite, vos fonctions de rappel sont utilisées chaque fois que le capteur reçoit un signal d’accélération.

Qt fonctionnant sur toute une série de plateformes, QWR fera de même et supportera toute une variété de plateformes. En tant que partie intégrante de Qt, cette technologie sera disponible ainsi que ses sources, selon le nouveau modèle de gouvernance (qui a notamment ouvert les repository de Qt sur Gitorious).

Ce framework est actuellement assez jeune et ne dispose pas encore de toutes les fonctionnalités qu’il devrait posséder à terme ni du support de nombreuses plateformes. Cependant, selon le modèle de contribution, chaque utilisateur pourra construire ce framework, grâce notamment à des retours dessus – vous aurez une place active dans son développement.

En attendant plus de détails, vous pourrez bien sûr aller sur le forum nouvellement ouvert du Qt Developer Network – en anglais uniquement. Le forum Plateformes et ceux de la rubrique Mobiles sont bien évidemment ouverts à toute question sur le sujet – en français !

Source : The Qt Web Runtime journey begins…

Voir aussi
Le réseau de développeurs Qt en beta publique : le Qt Developer Network veut rassembler toutes les connaissances sur Qt
Télécharger les préversion de QtWRT
La rubrique Qt de Developpez.com
La rubrique Mobiles de Developpez.com
La rubrique JavaScript de Developpez.com

Et vous ?

Développez-vous des applications qui tireraient profit d’un tel framework ? Quels avantages en retireriez-vous ? Quels en seraient les inconvénients ?

Le réseau de développeurs Qt en beta publique

Le 6 mai 2010 ouvrait le Qt Developer Network en beta privée. La première phase de l’ouverture du système. Il s’agissait alors de récupérer les bogues et autres dysfonctionnements de la centralisation des connaissances Qt, des documents internes à Nokia ou non. Notamment, ils reprennent quelques pièces déjà existantes : principalement les forums des Qt Labs, ces « ancêtres » seront d’ailleurs bientôt fermés. En plus, le portail fournit un wiki, un blog pleinement mature, une FAQ ainsi que le contenu résidant sur la zone développeurs du site de Nokia. Chaque contribution vous y apportera quelques points, selon un barème préétabli. 

Cette version beta publique apporte une grande nouveauté : les tags. Un tag est un mot-clé associé à du contenu pour le trier. Ce système de tag est étendu à tous les contenus : posts sur le forum, articles sur le wiki et tous les autres types de contenus à l’avenir, dont les vidéos des Qt Developer Days. 

Sources
Les Qt Labs (The Qt Developer Network Opens The Gates et The Qt Developer Network Is Finally Live). 

Voir aussi
Les vidéos des Qt Developer Days 2009 présentées en français
Le Qt Developer Network

Sortie de Qt 4.7 en beta 2 et d’une préversion de Qt Creator 2.1

La deuxième beta de Qt 4.7 est disponible sur la page de téléchargement de Qt. Les sources sont toujours disponibles ainsi que des binaires pour Mac OS X (Carbon et Cocoa), MinGW 4.4.0 et Visual Studio 2008.

La convention de nommage a évolué comme pour Qt 4.6.x au sujet des paquets à destination des utilisateurs de Mac OS X, pour refléter le fait que Cocoa est maintenant préféré pour Qt 4.7. Les paquets pour Carbon n’existeront plus à partir de Qt 4.8 mais seront toujours disponible pour toutes les version de Qt 4.7.x.

Le but de cette seconde version beta ? Modulariser un peu plus Qt (voir à ce sujet l’article d’Henry Haverinen : au final, Qt 4.7 ne devrait plus contenir le module Qt Multimedia, celui-ci étant intégré aux Qt Solutions) ainsi que fournir une base plus adaptée pour les tests et ainsi fournir une version finale d’encore meilleure qualité.

Des snapshots de Qt Creator 2.1 sont aussi disponibles aujourd’hui. En combinaison avec Qt 4.7 beta 2, ils fournissent une preview de Qt Quick. Cette version de Qt Creator contient une première version du Qt Quick Designer et peut travailler avec des projets Qt Quick, avec la possibilité d’éditer et de déboguer des fichiers QML. Pour ceux qui utilisent le repository Git, un tag v4.7.0-beta2 devrait apparaître bientôt.

Sources : les Qt Labs (Qt 4.7 Beta2 and Qt Creator 2.1 Snapshots Available et Qt 4.7 scope change regarding Qt Multimedia).

Et vous ?

Que pensez-vous du support de Qt Quick par Qt Creator ? Cette nouveauté va-t-elle révolutionner votre manière de coder ?
À propos de la modularisation de Qt, quels pourraient en être les avantages, tant pour les développeurs et mainteneurs du framework que pour ses utilisateurs ?