Re: [Starpu-devel] StarPU with Windows and Visual C++ port?

[George Russell <george@codeplay.com>]

Hi,

(I have attached a patch for the README, noting its good to update the 
Video drivers as older versions have bugs interfering with StarPU and 
OpencCL).
After updating the drivers on this machine, I can run examples from the 
source tree (e.g. examples\basic_examples\variable)

I guess I would like the README to discuss the process of building 
StarPU on Windows for use with OpenCL (from NVidia/ATI)  and for using 
StarPU from Visual Studio.

The current SVN builds are failing to generate .def files on Windows. 
(see below)
Configured as follows
 ./configure --with-opencl-dir=/c/prog/NVOpenCL --disable-cuda 
--disable-cpu --enable-verbose --enable-debug  --enable-opencl

$ make install
Making install in src
make[1]: Entering directory `/c/prog/StarPU/starpu/trunk/src'
make[2]: Entering directory `/c/prog/StarPU/starpu/trunk/src'
make[3]: Entering directory `/c/prog/StarPU/starpu/trunk/src'
test -z "/usr/local/lib" || /bin/mkdir -p "/usr/local/lib"
 /bin/sh ../libtool   --mode=install /bin/install -c   libstarpu.la 
'/usr/local/lib'
libtool: install: /bin/install -c .libs/libstarpu.lai 
/usr/local/lib/libstarpu.la
libtool: install: /bin/install -c .libs/libstarpu.a 
/usr/local/lib/libstarpu.a
libtool: install: chmod 644 /usr/local/lib/libstarpu.a
libtool: install: ranlib /usr/local/lib/libstarpu.a
make  install-exec-hook
make[4]: Entering directory `/c/prog/StarPU/starpu/trunk/src'
/bin/install -c .libs/libstarpu.def /usr/local/lib
/bin/install: cannot stat `.libs/libstarpu.def': No such file or directory
make[4]: *** [install-exec-hook] Error 1
make[4]: Leaving directory `/c/prog/StarPU/starpu/trunk/src'
make[3]: *** [install-exec-am] Error 2
make[3]: Leaving directory `/c/prog/StarPU/starpu/trunk/src'
make[2]: *** [install-am] Error 2
make[2]: Leaving directory `/c/prog/StarPU/starpu/trunk/src'
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory `/c/prog/StarPU/starpu/trunk/src'
make: *** [install-recursive] Error 1

On 24/02/2011 20:21, Cédric Augonnet wrote:
> Hi,
>
> We have one of our users who used StarPU that way already, his code 
> was developed under VS, and he linked with a .dll that was provided 
> from mingw. Within the PEPPHER project, Movidius simulator is another 
> example of code developed under VS and that used StarPU.
>
> Cédric
>
> On 24/02/2011 20:17, George Russell wrote:
> > Hi,
> >
> > It may be possible to make Mingw compiled .dll's that are usable from 
> > within Visual Studio, and that can also link with user code compiled 
> > in Visual Studio, and with OpenCL driver stacks for Windows; however, 
> > at present this is completely untested and may not work for some 
> > unforseen reason.
> >
> > I'd certainly be interested in testing such a combination, if the 
> > requisite wrappers around the Mingw compiled code could be made.
> >
> > Cheers,
> > George
> >
> >
> > On 24/02/2011 19:55, Cédric Augonnet wrote:
> > > On 24/02/2011 19:38, Samuel Thibault wrote:
> > > > George Russell, le Thu 24 Feb 2011 18:31:57 +0100, a écrit :
> > > > > I'd like to query if there is a possibility of StarPU being 
> > > > > officially ported
> > > > > to Windows via the Visual Studio development tools e.g. to compile 
> > > > > on Windows
> > > > > without the use of GCC and a Unix compatibility layer. The main 
> > > > > motivation of
> > > > > this would be to allow the use of StarPU on Windows with the 
> > > > > NVidia / AMD /
> > > > > Intel OpenCL SDKs on GPU / CPU, and our compilers that generate 
> > > > > OpenCL.
> > > > I'm not sure why we need to build StarPU with Visual Studio to make it
> > > > usable in Visual Studio?  Can't we just provide appropriate .h / .def
> > > > / .lib .visual-studio-stuff files?  We already do provide .h, .def and
> > > > .lib, I thought that was enough for Visual Studio to be happy (I 
> > > > have to
> > > > admit I have never actually used Visual Studio myself, however).
> > > >
> > > > The issue is that we don't use windows in our everyday work, and 
> > > > thus we
> > > > won't keep StarPU compilable by MSVC ourself. The MinGW approach 
> > > > permits
> > > > to at least share the compiler, which keeps a lot of compatibility
> > > > issues with MSVC away. Yes, we could make nightly MSVC builds of 
> > > > StarPU
> > > > to spot MSVC issues early, but doing it on the whole code will be 
> > > > quite
> > > > some work, while doing it just on the interface (.h, .def) should be
> > > > quite easy to keep working.
> > > >
> > > > Samuel
> > > Hello,
> > >
> > > Indeed, even within the PEPPHER framework, people would not have to 
> > > modify StarPU, so that if we manage to provide some standard 
> > > configuration (e.g. supporting OpenCL + CUDA), there is little point 
> > > in making it possible to recompile StarPU from VS. Everything that 
> > > was promised in the PEPPHER project should be doable without 
> > > modifying StarPU's sources (apart from fixing bugs of course).
> > >
> > > Keeping the code compatible to the numerous version of VS is 
> > > tedious, and since none of actually even has a VS installed, it's 
> > > clear that it would go unmaintained very soon so we cannot 
> > > realistically promise such as thing. I'm also unfamiliar with VS, 
> > > but does it make a different to take a .dll or some code compiled 
> > > from VS in terms of function name completion and so on ?
> > >
> > > That said, this confirms we really need to provide a nightly build 
> > > .dll/.def/.lib or whatever would help windows users.
> > >
> > > Best,
> > > Cédric

Index: README
===================================================================
--- README      (revision 3243)
+++ README      (working copy)
@@ -127,6 +127,10 @@
     copy c:\cuda\lib\cufft.lib c:\cuda\lib\libcufft.lib
     copy c:\cuda\lib\OpenCL.lib c:\cuda\lib\libOpenCL.lib
 
+- Update the video drivers to the latest stable release available for your
+  hardware. Older drivers contain bugs that cause OpenCL support in StarPU to
+  hang or exhibit incorrect behaviour.
+  
 ++===========++
 || V. Trying ||
 ++===========++