Science Sprint

Location, Date

OpenStreetMap GoogleMaps Access in 15 mn from the station with bus 34 (direction Sassenage) bus stop "Polygone Scientifique"

All participants need to be declared to be allowed to enter the site: Please register here



Coordination: Jérôme Kieffer: +33476882445 or

Coordination (Saturday): Andrea Prodi: +33648521922 or




Arrival at

Departure at

Traveling details


Frédéric-Emmanuel Picca


Sat 23.6.2012

Wed 27.6.2012

Train from Paris


Andreas Tille


Sat 23.6.2012

Tue 26.6.2012

Night train Hanover - Geneva -- feel free to join


Filippo Rusconi


Michael Hanke


Sat 23.6.2012

Tue 26.6.2012

Flying VRN->LYS->LEJ


Dominique Dumont


Sylvestre Ledru

Sun 24.6.2012

Mon 25.6.2012


Philippe Le Brouster

Sun 24.6.2012

Tue 26.6.2012


Sébastien Villemot

Sun 24.6.2012

Mon 25.6.2012


Julien Cristau

Sun 24.6.2012

Tue 26.6.2012


Topics to be addressed during the Sprint:


General report from the 3 days

More than 40 people attended to the workshop, it was great to realize how large the community was with people coming from all over Europe. We noticed we are facing the same problems in most of our facilities where HPC clusters are central point of the scientific activity. The input from P. Demichel from Hewlett-Packard gave a nice view on what the future of HPC is made of. The small workgroup around "OpenCL" had extremly valuable input from V. Danjean concerning the licencing issues and possible (forseeable) solutions. Systematic backports are a common need of most institutes as we all love the "rock-solid" debian stable and packager of scientific/HPC software should keep this in mind (i.e. not only unstable). M. Hanke exposed the solution he is working on for Neuro-debian (where they have similar issues). Last point concerning documention for debian packages and the deployment of HPC software on debian: the debian wiki is the best place to plut the documentation on (better indexed by google).

Some bugs were fixed during the Sprint itself on: OAR, OpenMPI, ?CodeAster, GMSH, Atlas ... and other.

Report from Andreas Tille

Thought on OpenCL by Vincent Danjean

Summary of the situation of OpenCL in Debian (06/2012)

===== OpenCL goals ======

What is important for Debian is that:

Mechanisms used to archieve all these goals

An application using OpenCL can compile with, and link directly at, a specific implementation (as in the MPI world). However, doing this will forbid most of the runtime choices presented in the previous paragraph.

The classical situation for OpenCL is that:

ICD Loaders and ICD

In therory (see below), any ICD Loader should be able to load and use any ICD. An ICD must implement some mandatory functions. One of these functions allows the ICD Loader to get the address of a structure which contains the address of all ICD implementation of OpenCL functions. Writing such an ICD Loader is easy once you know the order of the functions in the structure (list and order that the Khronos group restrict to its members and that the ocl-icd projet reverse engeenered)

never be removed (so that their won't be incompatibility between to ICD Loaders).

In pratice, we can really use the ICD Loader from Intel to use the NVidia ICD. But, there is no support for the ICD to declare which version of the structure it provides. An ICD can offers (through the structure) more functions. It happens when the ICD provides an OpenCL version greater than the one provided by the ICD Loader. This is not really a problem but the an OpenCL application using the more recent OpenCL version will not be able to link to the ICD Loader. It will then fail at link time.

OpenCL than the ICD. In this case, an OpenCL application using features from the new version will call the ICD Loader that will call the "function" at the address present in the memory after the end of the (old) structure provider by the ICD. This generally leads to a segfault.

information. Even if ICDs declare a supported OpenCL version, it is the OpenCL version for which the support is full. At the time of writing, the Intel ICD declare to support OpenCL 1.1 but provides to the ICD Loader the structure of OpenCL 1.2 *with* some address of functions specific to OpenCL 1.2 (but not all of them, hence the no declaration of OpenCL 1.2 support).

compilation time which version of OpenCL is supported. They will get the OpenCL version of the ICD Loader, but not the one of the ICD itself that will be loaded at runtime.

But non-free ICD Loaders (cnot ocl-icd for now) do not do any checks for non-NULL value before dispatching the call. So it is again easy to get segfault with some combination of program/ICD.

*language* (for the code dedicated to the target platforms). Of course, as the norm is not complete, or not fully implemented or implemented with extension, the portability of OpenCL code is not as good as one can hope. But there is little to do here with respect to Debian packaging.

===== Current packaging situation ======

Brief overview of sources packages/OpenCL implementations:

Overview of binary packages currently in sid (and probably testing) on amd64: ====== AMD =====


===== [ocl-icd] (version 1.3-2 currently in NEW or in my own repo) ======

Intel OpenCL SDK

======Virtual packages======

NOTE: libopencl1.0 is not proposed as a virtual package:

A few remarks:











AMD | ok | ok | MVS












MVS: missing version on symbol => a warning from the linker at program start MS: missing symbols. The linker can fail to find some symbols (NVidia ICD

BSO: the link must be present at runtime.

MSO: wrong soname:

This is the status around late June 2012 and things are likely to evolve

After a couple of exchanges with Intel about their OpenCL SDK; it turns out the software is re-distributable hence suitable to be packaged in "non-free".


the sprint has been possible thanks to: