I should mention that the version of 'accelerate' on hackage is a little old and unloved at the moment, but the source repo should work: https://github.com/mchakravarty/accelerate Also, the CUDA bindings package hasn't yet been tested/updated for the recent 4.0 toolkit release. -T On 05/07/2011, at 10:13 AM, Don Stewart wrote:

There's a lot of active work:

Direct access to CUDA: http://hackage.haskell.org/package/cuda CUDA in Haskell: http://hackage.haskell.org/package/language-c-quote Direct access to OpenCL: http://hackage.haskell.org/package/OpenCLRaw High-level pure data parallelism targetting your GPU: http://hackage.haskell.org/package/accelerate

On Mon, Jul 4, 2011 at 8:09 PM, Vasili I. Galchin wrote:

...

Hi,

NVIDIA's CUDA library seems to be really hot in the massively parallel world: http://www.nvidia.com/object/cuda_home_new.html. I realize that given CUDA seems to be implemented in an extension of ANSI C that it is pervaded by statefulness. However, is there any effort to build "a bridge" between Haskell and CUDA, foreign language bindings or maybe better yet a monad to encapsulate state??

Kind regards,

Vasili

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

hmm... so libcuda and libcudart are in /usr/local/cuda/lib and the script isn't finding them? Any further information on your system / os combination? What version of the toolkit are you using? I currently use 3.2, haven't tried with 4.x yet.

$ nvcc --version nvcc: NVIDIA (R) Cuda compiler driver Copyright (c) 2005-2010 NVIDIA Corporation Built on Thu_Nov_11_15:26:50_PST_2010 Cuda compilation tools, release 3.2, V0.2.1221

On 05/07/2011, at 10:16 PM, Johannes Waldmann wrote:

Trevor L. McDonell writes:

...

... source repo should work: https://github.com/mchakravarty/accelerate

I have CUDA in the default location (e.g., /usr/local/cuda/bin/nvcc ) but I can't seem to get the cuda cabal package to build

... checking cuda.h usability... yes checking cuda.h presence... yes checking for cuda.h... yes checking cuda_runtime_api.h usability... yes checking cuda_runtime_api.h presence... yes checking for cuda_runtime_api.h... yes checking for library containing cuDriverGetVersion... no configure: error: could not find CUDA driver library

I have nvcc in the PATH, and I also set --extra-include/lib-dirs

I can build and run the NVIDIA_GPU_Computing_SDK examples.

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On 07/07/2011, at 1:36 AM, Johannes Waldmann wrote:

actually libcuda is in /usr/lib/nvidia-current ...

It still feels strange that I can build the examples from NVIDIA_GPU_Computing_SDK/C/src/ without modifying LDFLAGS.

Okay. I've modified to configure script to fix the extra space issue, and to push LDFLAGS and CFLAGS onto the environment before cabal attempts the build. It should also correctly handle the --extra-[lib,include]-dirs flags now. Hopefully that goes smoother in future... I had a look though the makefiles used by the NVIDIA examples on my ubuntu test machine, but found no mention of searching /usr/lib/nvidia-current, so I'm not sure where that came from. Maybe that's part of the examples installer script, but I'll have to look into that later.

Anyway, when running "accelerate-examples --cuda" I get mixed results,

Is there a way to find out the expected results/failures for a recent accelerate package install? (So I can avoid reporting them.)

That is a good point. Some of the tests are expected to fail but that's not written down anywhere yet; I'll add a README. The stack overflow errors come from the reference implementations, not the accelerate code; give the RTS more space to play in with "+RTS -K32M" or similar. Off the top of my head permute-hist, radixsort, one of the slice tests, and scanseg-sum fail. Thanks for the bug reports so far! -Trev