I've been trying to install pycuda on my centos 5.3 box, but I haven't had
much success. I managed to install boost (1.39) as per instructions, but when
I build pycuda I get the following error:
building '_driver' extension
gcc -pthread -fno-strict-aliasing -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2
-fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic
-D_GNU_SOURCE -fPIC -O3 -DNDEBUG -fPIC -Isrc/cpp -I/usr/include/boost-1_39
-c src/wrapper/wrap_cudadrv.cpp -o
src/wrapper/wrap_cudadrv.cpp: In function
src/wrapper/wrap_cudadrv.cpp:165: error: ‘PyErr_WarnEx’ was not
declared in this scope
error: command 'gcc' failed with exit status 1
I looked around for a solution, but I couldn't find any. I'm using
and my default gcc version is 4.1.2 (although I had to compile boost
Thanks in advance for your help,
Out of curiosity, has anyone had any success with OpenGL in pycuda?
I have searched through the past messages on the list that I could find, and
it did not seem that the issue was ever resolved. Does anyone have any
For the list...
On Wed, Aug 12, 2009 at 11:39 AM, M. Badawy<m.cohomology(a)gmail.com> wrote:
> From what I have read so far, it seems that using Matlab w/
> AccelerEyes' Jacket seems to be the fastest and easiest method to use
> CUDA w/ Matlab. So, assuming that I'll be using Jacket, is there a
> significant performance
> difference between this option and using Pycuda?
I haven't used Jacket, maybe someone else can comment.
There will not be any difference in the GPU computation whether you
use mex or PyCUDA because the underlying kernels are in C anyway; but
I think Jacket generates its own kernels so it might be faster or
slower depending on how smart their compiler is, but at this stage, I
suspect a compiler wouldn't be that much better at tuning a CUDA
kernel than a human (might be a lot worse).
I used PyCUDA with great success from Sage (then just Python with
Numpy, etc.); then I wrote a mex interface to set up and call my
kernels from Matlab. The latter took a lot more effort because you
have to set up your device and convert your datastructures (e.g.,
structure-of-arrays to array-of-structures for complex numbers) and
handle transfers and free memory manually in C. And SciPy can save
data to Matlab-compatible .mat files anyway for good
I also want my implementation to be open-source one day, and don't
want to force my colleagues to have copies of Matlab and Jacket.
I was trying to install pycuda today from source (in advance of the Scipy
tutorial!), and have noticed a problem if I don't use eggs to install. If I
python setup.py install --single-version-externally-managed --root=/
I get the pycuda header file installed under usr/include/cuda. This breaks
the logic in compiler._find_pycuda_include_path().
I personally avoid eggs, so this creates a problem. Also, many linux
package managers (including Gentoo, my own distro) avoid eggs, and I know
for a fact that Gentoo uses this same method to install packages. I've
hacked my own compiler.py to work, but I'm not sure what a good solution
really would be. Gentoo has 0.92 packaged, but I don't think the header was
used in that version and thus didn't present any problems.
Graduate Research Assistant
School of Meteorology
University of Oklahoma
Hi everyone...This is my first message and I have a rather simple
(read naive :)) question but it is important in that it will affect a
major decision to go one way or the other. I'm an applied
Mathematician and although I'm familiar with Matlab, I'm not a big fan
and Python/Sage look much more interesting.
I understand that Matlab now can make use of CUDA, and given that I'll
be running my code on a home desktop PC running Ubuntu linux, is there
any kind of performance comparison between Pycuda and Matlab right
I've updated the wiki with my configuration of Windows Vista 64 bit with
Visual Studio 2008. To use it, your entire python stack must also be 64 bit.
The build was x64, also known as amd64.
I also have a question: is it possible to statically compile all embedded
kernels in my code with pycuda? Deploying a program with pycuda widely with
because it requires the cuda and c++ build tools, which are heavy. It would
be nice to have an option to generate a library at build time that could
then be packaged and installed without having to do the heavy c lifting.
View this message in context: http://n2.nabble.com/Installation-wiki-updated-with-Windows-Vista-64-bit-in…
Sent from the PyCuda mailing list archive at Nabble.com.
Is there a way to get a list of the global variables, especially
constant arrays and texture refs that are defined in a kernel?
I'm generating a pycuda.driver.Module from a template, and the storage
of various kernel inputs depends on the template parameters.
It would be convenient for code using a kernel generated this way to
have some way of figuring out what global variables are defined in the
kernel, and whether they are globals, constants, or texrefs.
Maybe in a future version of pycuda it would be nice to replace (or
provide an alternative to) the accessor functions:
that consists of having member variables:
that are already initialized to dictionaries with the name of the
variable as the key, and the handle (or maybe a (handle, size) tuple)
as the value.
or maybe have a single member variable pycuda.driver.Module.globals
that is a dictionary with variable names as keys, and a (type, handle,
size) tuple or something similar.
If I at least have the name of the variable I think I can deduce if
the variable is defined as a __constant__ array by wrapping
pycuda.driver.Module.get_global in a try: statement, but that's rather
Or perhaps I'm misunderstanding something and the Module.get_*
functions are forced on us by the CUDA API?
It has finally happened: 0.93 is out! The online docs have been updated to
match the release where that was not the case. As always, the complete list of
changes can be found here:
Here are a few of the most exciting that have happened this cycle:
* Reductions (sums, norms, inner products)
* GL interoperability
* CUDA 2.2 support
Relatedly, master has picked up support for sparse matrix-vector
multiplication just today. And with that: Onwards to 0.94! :)