Hi everybody,
I am new on PyCuda. I just installed everything on Windows XP and, from the installation log, I think that I did it properly. However, I tried to run the test files provided with pycuda and I get this error
Traceback (most recent call last):
File "C:\PyCuda\test\test_gpuarray.py", line 2, in <module>
import pycuda.autoinit
File "C:\PyCuda\pycuda\autoinit.py", line 1, in <module>
import pycuda.driver as cuda
File "C:\PyCuda\pycuda\driver.py", line 1, in <module>
from _driver import *
ImportError: No module named _driver
how can I solve it?
thanks and sorry for the newbieness of this post
den3b
_________________________________________________________________
I tuoi amici sempre a portata di clic, sul nuovo Web Messenger
http://www.windowslive.it/foto.aspx
On Fri, 21 May 2010 13:24:51 +0100, "Samuel Powell" <spowell(a)medphys.ucl.ac.uk> wrote:
> Hi Andreas,
>
> You are correct in your assertion.
>
> I followed your advice by packaging some of the pyCuda example scripts using
> py2exe before executing them. In the majority of cases, I found no problem
> executing the packaged code.
>
> If, as you suggest, the launch failure is likely caused by a segfault on the
> device, I think the best course of action is for me to dissect the CUDA
> kernel until it runs correctly, thus identifying where the bad addressing
> comes into play.
>
> Would you agree with this analysis?
That sounds plausible.
Good luck with your bug hunting,
Andreas
PS: Please keep the list cc'd when replying. Thx!
Dnia 2010-05-20, czw o godzinie 04:40 -0400, Yaroslav Halchenko pisze:
> lintian is your friend -- make sure you address all the warnings one
> way or another -- I looked at pytools briefly:
>
> $> lintian pytools_10_amd64.changes
> W: pytools source: non-native-package-with-native-version
> W: pytools source: build-depends-on-1-revision build-depends: python (>= 2.5-1)
> W: pytools source: build-depends-on-1-revision build-depends: python-dev (>= 2.5-1)
> W: python-pytools: extended-description-line-too-long
> W: python-pytools: possible-unindented-list-in-extended-description
> W: python-pytools: wrong-section-according-to-package-name python-pytools => python
> W: python-pytools: copyright-without-copyright-notice
> W: python-pytools: binary-without-manpage usr/bin/logtool
> W: python-pytools: binary-without-manpage usr/bin/runalyzer
> W: python-pytools: binary-without-manpage usr/bin/runalyzer-gather
>
Thanks for advice - I have removed all problems pointed by lintian.
>
> also I bet they would work fine with python >= 2.5 so why
> XS-Python-Version: 2.5
Removed.
I also managed to create private repository.
Now anyone using Debian with architecture amd64 can add
following lines to /etc/apt/sources.list
deb http://www.bogomips.w.tkb.pl . .
deb-src http://www.bogomips.w.tkb.pl . .
(there are two dots separated by space)
then `apt-get update && apt-get install python-pycuda`
and PyCUDA should be installed.
With Ubuntu there can be problem with missing package
libcuda1 - but I would like for someone to try it
nonetheless (just download *.deb files and dpkg -i *.deb)
and report whether packages are working.
Regards.
--
Tomasz Rybak <bogomips(a)post.pl> GPG/PGP key ID: 2AD5 9860
Fingerprint A481 824E 7DD3 9C0E C40A 488E C654 FB33 2AD5 9860
http://member.acm.org/~tomaszrybak
Dnia 2010-05-15, sob o godzinie 19:49 -0400, Yaroslav Halchenko pisze:
> > PS. This message is being sent to two lists: pycuda and
> > Debian nvidia packaging.
> so now I wouldn't know either it is worth for me following up or someone
> already resolved the issues
For now you are the only person that answered.
>
> On Sat, 15 May 2010, Tomasz Rybak wrote:
> > The very first version of packages can be found at my page
> > http://www.bogomips.w.tkb.pl/cuda.html
> cool
>
> but where is actual packaging? how did you generate .deb, .dsc,
> .changes?
I have:
1. downloaded source (git clone)
2. added my debian/ directory
2a. I used Format: 3.0 git, so I had to add debian/ to .gitignore
3. run dpkg-buildpackage -rfakeroot and result of it put on the
web page.
So all changes performed by me are in pycuda_0.94-1.git.tar.gz
in debian/ directory.
>
> > Another problem is version - I have put v 0.94 while
> > pycuda is in version 0.94rc. When I will read how to version
> make it 0.94~rc
OK.
>
> > packages downloaded from git repository I will change that.
> you could add a date, e.g. 0.94~rc+20100515
>
> > What is license of PyCUDA? I assume it is MIT, but where can I confirm
> > this?
> look at my ITP (I think I should have listed one), check with upstream,
> use licensecheck to confirm you've not missed any
>
> > Debian Python packages should have names starting with python-*.
> > Should this package be named python-cuda or python-pycuda?
> since module is pycuda, should be python-pycuda
OK.
>
> P.S. have you had a look at python packaging policy and debian policy
> and developer reference (at least in parts) before?
>
I have read maintainers-guide, and want to read Python policy
(but have not read it yet).
--
Tomasz Rybak <bogomips(a)post.pl> GPG/PGP key ID: 2AD5 9860
Fingerprint A481 824E 7DD3 9C0E C40A 488E C654 FB33 2AD5 9860
http://member.acm.org/~tomaszrybak
On Fri, 21 May 2010 16:56:49 +0200, Dan Goodman <dan(a)thesamovar.net> wrote:
> On 21/05/2010 12:55, Andreas Kloeckner wrote:
> > On Wed, 19 May 2010 17:22:03 +0200, Dan Goodman<dan(a)thesamovar.net> wrote:
> >> Hi Andreas,
> >>
> >> Sorry about posting that overly large file strace.txt to the list -
> >> hadn't noticed it was so big. I think I sent a copy directly to you too
> >> so that if you want to take a look you can do so?
> >
> > I got it, though it crashed my email client, and so it took a while
> > until I had the motivation to dig it out of my raw email files. But I
> > finally did, and it's been pretty informative, I think.
> >
> > Everything seems to be going normally until nvcc spawns a copy of (I
> > think) gcc as pid 26628, which then dies after
> >
> > [pid 26628] write(1, "*asm:\n%{v:-V} %{Qy:} %{!Qn:-Qy} "..., 4935) = -1 EBADF (Bad file descriptor)
> >
> > Immediately after that, 26627 (an nvcc instance) goes into an infinite
> > read loop, because it apparently can't believe that it got nothing back
> > From gcc. (i.e. that's an nvcc bug) My guess at what's wrong here starts
> > a bit earlier though. It seems that nvcc unconditionally closes fd 0 and
> > 1 before spawning gcc, on the assumption that those are
> > stdin/stdout. That doesn't appear to be the case, because open returns
> > '0' a few times, which indicates to me that stdin/stdout aren't open any
> > more by that time. The solution would thus be for you to open some
> > 'fake' stdin and stdout files at the start of your spawned
> > process. (/dev/null?)
>
> So, yes indeed that solves the problem. For the moment at
> least, we can put something in our code that just redirects stdin/out to
> null. Is this something that could be addressed in pycuda or is it an
> unavoidable thing given the nvcc bug? Perhaps we should let them know
> about it, in that case.
If you could file a bug report with Nvidia about nvcc unconditionally
closing fds 0/1, I think that would be the most helpful. Then you can
keep your workaround for as long as it's needed, and the problem will
eventually (hopefully) vanish. Addressing this PyCUDA is a bit weird,
because it adds an extra layer of non-portable cruft.
Out of curiosity--how do you detect if an FD is open on Linux/Unix?
Andreas
PS: Please keep the list cc'd.
Hi!
I installed PyCuda 0.93/Cuda 2.3 on my computer (Win7-32bit, Xeon W3520 , GTX285) and after some troubles it seemed to execute the examples without problems. Then I started test_gpuarray_random.py and it shows a gpu speed up around 1e-7 (so the cpu is 10 million times faster ). It seems there is something wrong.
[C:pycuda-0.93/examples]|2> run test_gpuarray_speed_random.py
1024
kernel.cu
tmpxft_00001618_00000000-3_kernel.cudafe1.gpu
tmpxft_00001618_00000000-8_kernel.cudafe2.gpu
kernel.cu
tmpxft_00000974_00000000-3_kernel.cudafe1.gpu
tmpxft_00000974_00000000-8_kernel.cudafe2.gpu
2048
4096
8192
16384
32768
65536
131072
262144
524288
1048576
2097152
4194304
8388608
16777216
Size |Time GPU |Size/Time GPU|Time CPU |Size/Time CPU |GPU vs CPU speedup
--------+----------------+-------------+-----------------+-----------------+------------------
1024 |0.00725786230469|141088.375201|2.88000004366e-09|355555550165.0 |3.96811061268e-07
2048 |0.00724965625 |282496.152835|2.88000004366e-09|711111100331.0 |3.97260220946e-07
4096 |0.00723105859375|566445.416932|2.91200005449e-09|1.40659338027e+12|4.02707296136e-07
8192 |0.00733181494141|1117322.25451|2.97600007616e-09|2.7526881016e+12 |4.0590223566e-07
16384 |0.00751718310547|2179539.83163|2.91200005449e-09|5.62637352108e+12|3.87379157011e-07
32768 |0.00753562646484|4348410.86576|2.91200005449e-09|1.12527470422e+13|3.86431050966e-07
65536 |0.00768003027344|8533299.69631|2.88000004366e-09|2.27555552106e+13|3.74998527496e-07
131072 |0.00763785009766|17160850.0199|2.94400006533e-09|4.45217381425e+13|3.85448788296e-07
262144 |0.0091615 |28613654.9692|2.91200005449e-09|9.00219763374e+13|3.17851886099e-07
524288 |0.00921462597656|56897371.7798|2.91200005449e-09|1.80043952675e+14|3.16019343802e-07
1048576 |0.0095365390625 |109953515.959|2.97600007616e-09|3.52344077005e+14|3.12062904231e-07
2097152 |0.0102445153809 |204709732.187|2.94400006533e-08|7.1234781028e+13 |2.87373287645e-06
4194304 |0.0117750354004 |356203090.469|2.91200005449e-08|1.4403516214e+14 |2.47302870478e-06
8388608 |0.0144500805664 |580523268.466|2.84800003283e-08|2.9454381683e+14 |1.97092328983e-06
16777216|0.0199746191406
16777216||839926703.077|2.94400006533e-08|5.69878248224e+14|1.4738704375
16777216|8e-06
Thanks,
Georg
Georg Teichtmeister, Bakk. techn.
JOANNEUM RESEARCH
Institute of Digital Image Processing
Wastiangasse 6
A-8010 Graz, Austria
Tel.: +43(316)876-1778
Fax: +43(316)876-9-1778
E-Mail: georg.teichtmeister(a)joanneum.at
On Wed, 19 May 2010 17:22:03 +0200, Dan Goodman <dan(a)thesamovar.net> wrote:
> Hi Andreas,
>
> Sorry about posting that overly large file strace.txt to the list -
> hadn't noticed it was so big. I think I sent a copy directly to you too
> so that if you want to take a look you can do so?
I got it, though it crashed my email client, and so it took a while
until I had the motivation to dig it out of my raw email files. But I
finally did, and it's been pretty informative, I think.
Everything seems to be going normally until nvcc spawns a copy of (I
think) gcc as pid 26628, which then dies after
[pid 26628] write(1, "*asm:\n%{v:-V} %{Qy:} %{!Qn:-Qy} "..., 4935) = -1 EBADF (Bad file descriptor)
Immediately after that, 26627 (an nvcc instance) goes into an infinite
read loop, because it apparently can't believe that it got nothing back
From gcc. (i.e. that's an nvcc bug) My guess at what's wrong here starts
a bit earlier though. It seems that nvcc unconditionally closes fd 0 and
1 before spawning gcc, on the assumption that those are
stdin/stdout. That doesn't appear to be the case, because open returns
'0' a few times, which indicates to me that stdin/stdout aren't open any
more by that time. The solution would thus be for you to open some
'fake' stdin and stdout files at the start of your spawned
process. (/dev/null?)
HTH,
Andreas
Hi all,
At the recent PyCon Quattro, which took place in early May in the
beautiful Tuscan city of Florence, Fabrizio Milo gave a talk on PyCUDA
entitled
PyCUDA: Come sfruttare la potenza delle schede video nelle
applicazioni python (PyCUDA: How to make use of the power of
graphics cards in Python applications)
http://www.pycon.it/conference/talks/pycuda-come-sfruttare-la-potenza-delle…
He made a set of rather nice slides (in English), which may be of
interest. They are downloadable in PDF form at the link.
Thanks Fabrizio for taking the time to talk about PyCUDA!
Andreas
Hi,
I have written a PyCuda based simulation code that successfully executes
when run normally with Python. I need to distribute this code to my
colleagues - owing to the large number of package dependencies and potential
unfamiliarity with Python I have been attempting to package the code using
Py2Exe.
Execution of the code via the Py2Exe-generated executable leads to a launch
timeout when the code attempts to run the CUDA kernel.
Traceback (most recent call last):
File "gui.pyc", line 236, in simulate
File "controller.pyc", line 131, in simulate
File "pycuda\driver.pyc", line 169, in function_call
pycuda._driver.LaunchError: cuCtxSynchronize failed: launch timeout
During the attempted launch the graphics output of the machine is frozen.
Note that the code successfully communicates with the card via CUDA prior to
launching the kernel (transferring various constants/textures).
Can anyone offer any advice as to how to fix this problem, or, indeed, how
to debug it!?
Regards,
Sam.
--
Samuel Powell
Doctoral Research Student
Biomedical Optics Research Laboratory
Dept. of Medical Physics & Bioengineering Malet Place Engineering Building
University College London London, WC1E 6BT, UK
[This mail bounced yesterday, I'm re-posting with a fix].
To follow-up - the problem with the Internal Compiler Error on Windows
persists with CUDA 3.0 as well.
One solution is to comment out the two blocks of code that reference
double_limit and rebuild pyCUDA.
The better solution is to replace:
#define DBL_MAX
179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.0
in pycuda-complex-impl.hpp
with
#define DBL_MAX 1.7976931348623158e+308
which is copied from MSVC's float.h.
After rebuilding my complex number code works as expected with no
Internal Compiler Errors.
Andreas - I know you'd prefer a patch but I'm not sure of the right
cross-platform/compiler way to add a conditional #define (the original
code works fine on my Mac with gcc). I hope this helps (I'll be back
with this client in mid June if a fix needs testing).
Cheers,
Ian.
On 13 May 2010 14:11, Ian Ozsvald <ian(a)ianozsvald.com> wrote:
> To follow-up - the problem persists with CUDA 3.0. I've upgraded on
> Windows to CUDA 3.0 and nvidia driver 197.45, the internal compiler
> error isn't affected. The solution (comment out the two blocks that
> reference double_limit) continues to work.
> Ian.
>
> On 12 May 2010 15:53, Ian Ozsvald <ian(a)ianozsvald.com> wrote:
>> Actually there *is* a bug in here, it just hides behind cached code.
>> It occurs for both cumath calls and SourceModules if you use complex
>> numbers.
>>
>> On Windows XP 32 bit (CUDA 2.3, Python 2.6, Microsoft Visual Studio
>> 2008/VS9) with pyCUDA0.94rc I can consistently generate an Internal
>> Compiler Error like the following:
>> ----
>> C:/Python26/lib/site-packages/pycuda-0.94rc-py2.6-win32.egg/pycuda/../include/pycuda\pycuda-complex-impl.hpp(350)
>> : fatal error C1001: An internal error has occurred in the compiler.
>> (compiler file 'msc1.cpp', line 1411)
>> To work around this problem, try simplifying or changing the program
>> near the locations listed above.
>> Please choose the Technical Support command on the Visual C++
>> Help menu, or open the Technical Support help file for more information
>> Internal Compiler Error in C:\Program Files\Microsoft Visual Studio
>> 9.0\VC\bin\cl.exe. You will be prompted to send an
>> error report to Microsoft later.
>> ----
>>
>> The problem lies in pycuda-complex-impl.hpp on lines 349-350 and
>> 401-402, these lines are:
>> __device__ complex<double> tan(const complex<double>& z)
>> { return tanT(z, double_limit); }
>> and
>> __device__ complex<double> tanh(const complex<double>& z)
>> { return tanhT(z, double_limit); }
>>
>> Commenting out these two blocks and recompiling pyCUDA makes the
>> problem go away (though of course there's no double precision support
>> for tan and tanh at that point). I only have a single precision card
>> so I'm ignoring this problem for now.
>>
>> These two functions are the only ones that use double_limit:
>> #define double_limit ::log(DBL_MAX)
>> which I'm presuming is the culprit. Possibly the choice of DBL_MAX is
>> the problem, maybe the number needs to be different on Windows 32
>> bit/msvc?
>>
>> I'm flagging this so someone else knows what's going on if they hit the error,
>> Ian.
>>
>> On 10 May 2010 16:37, Ian Ozsvald <ian(a)ianozsvald.com> wrote:
>>> Problem solved - user error had occurred. The MacBook had a full
>>> checkout of HEAD and worked infe, the Windows machine appeared to have
>>> everything as well (and git reported being up to date with no
>>> modifications) but somehow I lacked "}}" at the end of
>>> pycuda-complex-impl.hpp (which took a fair while to diagnose).
>>>
>>> On the up side I do now have a rather good understanding of the
>>> internals of code generation in pyCUDA and the tan(complex) support is
>>> absolutely spot-on - many thanks!
>>>
>>> Righto, back to the task at hand and sorry for the bad bug report,
>>> Ian.
>>>
>>> On 10 May 2010 08:15, Andreas Klöckner <lists(a)informa.tiker.net> wrote:
>>>> On Freitag 07 Mai 2010, Ian Ozsvald wrote:
>>>>> l error C1001: An internal error has occurred in the compiler.
>>>>> (compiler file 'msc1.cpp', line 1411)
>>>>
>>>> Here's one idea: The code refers to environment-provided trig functions
>>>> as ::sin, i.e. using the double-colon namespace escape. Perhaps it helps
>>>> to remove those double colons?
>>>>
>>>> Beyond that, I'm not sure I can help--an ICE is a compiler bug.
>>>>
>>>> Andreas
>>>>
>>>
>>>
>>>
>>> --
>>> Ian Ozsvald (A.I. researcher, screencaster)
>>> ian(a)IanOzsvald.com
>>>
>>> http://IanOzsvald.com
>>> http://morconsulting.com/
>>> http://TheScreencastingHandbook.com
>>> http://ProCasts.co.uk/examples.html
>>> http://twitter.com/ianozsvald
>>>
>>
>>
>>
>> --
>> Ian Ozsvald (A.I. researcher, screencaster)
>> ian(a)IanOzsvald.com
>>
>> http://IanOzsvald.com
>> http://morconsulting.com/
>> http://TheScreencastingHandbook.com
>> http://ProCasts.co.uk/examples.html
>> http://twitter.com/ianozsvald
>>
>
>
>
> --
> Ian Ozsvald (A.I. researcher, screencaster)
> ian(a)IanOzsvald.com
>
> http://IanOzsvald.com
> http://morconsulting.com/
> http://TheScreencastingHandbook.com
> http://ProCasts.co.uk/examples.html
> http://twitter.com/ianozsvald
>
--
Ian Ozsvald (A.I. researcher, screencaster)
ian(a)IanOzsvald.com
http://IanOzsvald.comhttp://morconsulting.com/http://TheScreencastingHandbook.comhttp://ProCasts.co.uk/examples.htmlhttp://twitter.com/ianozsvald
