Hello.
I've been packaging PyCUDA for Debian.
I run all the tests to ensure that package works on Python 2
and Python 3. All tests pass except for on from test_driver.py:
$ python test_driver.py
============================= test session starts
==============================
platform linux2 -- Python 2.7.5 -- pytest-2.3.5
collected 21 items
test_driver.py ........F............
=================================== FAILURES
===================================
_____________________ TestDriver.test_register_host_memory
_____________________
args = (<test_driver.TestDriver instance at 0x24e7d88>,), kwargs = {}
pycuda = <module 'pycuda' from
'/usr/lib/python2.7/dist-packages/pycuda/__init__.pyc'>
ctx = <pycuda._driver.Context object at 0x2504488>
clear_context_caches = <function clear_context_caches at 0x1dbf848>
collect = <built-in function collect>
def f(*args, **kwargs):
import pycuda.driver
# appears to be idempotent, i.e. no harm in calling it more than
once
pycuda.driver.init()
ctx = make_default_context()
try:
assert isinstance(ctx.get_device().name(), str)
assert isinstance(ctx.get_device().compute_capability(),
tuple)
assert isinstance(ctx.get_device().get_attributes(), dict)
> inner_f(*args, **kwargs)
/usr/lib/python2.7/dist-packages/pycuda/tools.py:434:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _
self = <test_driver.TestDriver instance at 0x24e7d88>
@mark_cuda_test
def test_register_host_memory(self):
if drv.get_version() < (4,):
from py.test import skip
skip("register_host_memory only exists on CUDA 4.0 and
later")
import sys
if sys.platform == "darwin":
from py.test import skip
skip("register_host_memory is not supported on OS X")
a = drv.aligned_empty((2**20,), np.float64, alignment=4096)
> drv.register_host_memory(a)
E LogicError: cuMemHostRegister failed: invalid value
test_driver.py:559: LogicError
==================== 1 failed, 20 passed in 116.85 seconds
=====================
This test fails both on ION (GeForce 9400M, CC 1.1) and GeForce 460
(CC 2.1). I've compiled PyCUDA with gcc 4.8, run with kernel 3.9
and drivers 304.88.
Regards.
--
Tomasz Rybak GPG/PGP key ID: 2AD5 9860
Fingerprint A481 824E 7DD3 9C0E C40A 488E C654 FB33 2AD5 9860
http://member.acm.org/~tomaszrybak
Hello,
I've got a host-side CUDA library wrapped in Cython and I'd like to use
it on a device-side array that I've allocated in python with PyCuda.
However, I'm completely at a loss as to how I should pass the device
pointers from the python side of things to the C library. In CUDA the
device pointers look like normal pointers, but in PyCuda I get a
DeviceAllocation object -- how can I pass the pointer address
information to the C library through Cython? What types should I use in
the Cython wrapper?
thanks!
Rok
Hey,
Just started working with PyCUDA, and already very taken with it, it makes a whole load of things very simple. Already after a couple of days I have a working program with OpenGL interop using PySide to provide the GUI and CUDA doing 3D texture lookups. One thing I haven’t been able to figure out yet though is how to pass vector arguments to CUDA kernels. I have a function definition like this:
__global__ void extract_slice(uchar4 *destPbo,
unsigned int width,
unsigned int height,
float3 center,
float3 xDelta,
float3 yDelta)
but I can’t make this work with pycuda passing in float3 variables like this:
self.kernel.prepared_call(grid_dimensions, (16, 16, 1),
target_mapping.device_ptr(),
self.width(),
self.height(),
pycuda.gpuarray.vec.make_float3(0.0, 0.0, 0.0),
pycuda.gpuarray.vec.make_float3(1.0, 0.0, 0.0),
pycuda.gpuarray.vec.make_float3(0.0, 1.0, 0.0)
)
so instead I have had to resort to just passing in 9 floats instead of 3 float3 variables, these are then reconstructed into float3s in the kernel and everything works correctly. While this is a solution for the moment I would really like to figure out how to pass vector types like this, and if anyone can point me in the right direction it would be much appreciated.
Thanks,
Ben
OHey pycuda-list,
I have some kernels which will be used over and over again, but as the compile time of them is pretty high (something like half an hour, for some hundred kernels). I would like to ensure that they are stored permanently on my computer, as opposed to the storage in the tmp folder, where they are deleted at some time.
Is there a way to customize the folder in which those compiler caches are stored?
And is there a way to find out which of the folders belong to which kernel?
Cheers,
Andreas Baumbach
Hello, I receive the above error when I try to run a pycuda code.
I use sabayon linux and this happened after an update at which it installed
the cuda toolkit 5.5
I tried to install again pycuda through:
python configure.py --cuda-root=/opt/cuda/
At start ,it gives me WARNING: nvcc not in path
If I do nvcc in terminal it gives "nvcc fatal : No input files specified;
use option --help for more information
" ,but I can compile and run cu programs.
My ~/.bashrc:
export PATH=~/bin:$PATH
export PATH=/opt/cuda/bin:$PATH
export PATH=~/opt/bin:$PATH
export LD_LIBRARY_PATH=/opt/cuda/lib64:$LD_LIBRARY_PATH
export CUDA_ROOT=/opt/cuda/bin
I had a similar thread
http://pycuda.2962900.n2.nabble.com/nvcc-not-in-path-td7574709.html
<http://pycuda.2962900.n2.nabble.com/nvcc-not-in-path-td7574709.html> but
it didn't help now.
(If I do echo $LD_LIBRARY_PATH as root it doesn't return anything.)
Any help please?
Thank you!
--
View this message in context: http://pycuda.2962900.n2.nabble.com/ImportError-libcurand-so-5-0-cannot-ope…
Sent from the PyCuda mailing list archive at Nabble.com.
Hi Graham,
Graham Mills <13gm10(a)queensu.ca> writes:
> I looked back about a year in the archives and couldn't find anything on this. I just downloaded and built cgen 2013.1.2 and codepy 2013.1.2 today. When using thrust as in the example at http://wiki.tiker.net/PyCuda/Examples/ThrustInterop , several python version-related errors crop up in cgen and codepy modules, such as
>
> File "/usr/local/lib/python3.2/dist-packages/codepy-2013.1.2-py3.2.egg/codepy/toolchain.py", line 153, in get_dependencies
> lines = join_continued_lines(stdout.split("\n"))
> TypeError: Type str doesn't support the buffer API
>
> and
>
> File "/usr/local/lib/python3.2/dist-packages/cgen-2013.1.2-py3.2.egg/cgen/__init__.py", line 893, in get_namespace_name
> checksum.update(line)
> TypeError: Unicode-objects must be encoded before hashing
>
> for instance. I manually fixed a few of the issues in my installation, but there are a few I cannot figure out. Retracing my steps back to building the installation, when build_py_2to3 gets called in setup.py it misses these lines (and others). Manually calling 2to3 doesn't catch them, either.
>
> Is there another release of codepy or cgen I should be using with python 3.2?
you're probably the first to try this with Py3. :) Python 3 support in
PyCUDA is fairly recent after all. If you could post/pull-request your
fixes as well as tests for the stuff you're stuck on, I'd be happy to
take a look and help get this fixed.
Andreas
Hi all,
I looked back about a year in the archives and couldn't find anything on this. I just downloaded and built cgen 2013.1.2 and codepy 2013.1.2 today. When using thrust as in the example at http://wiki.tiker.net/PyCuda/Examples/ThrustInterop , several python version-related errors crop up in cgen and codepy modules, such as
File "/usr/local/lib/python3.2/dist-packages/codepy-2013.1.2-py3.2.egg/codepy/toolchain.py", line 153, in get_dependencies
lines = join_continued_lines(stdout.split("\n"))
TypeError: Type str doesn't support the buffer API
and
File "/usr/local/lib/python3.2/dist-packages/cgen-2013.1.2-py3.2.egg/cgen/__init__.py", line 893, in get_namespace_name
checksum.update(line)
TypeError: Unicode-objects must be encoded before hashing
for instance. I manually fixed a few of the issues in my installation, but there are a few I cannot figure out. Retracing my steps back to building the installation, when build_py_2to3 gets called in setup.py it misses these lines (and others). Manually calling 2to3 doesn't catch them, either.
Is there another release of codepy or cgen I should be using with python 3.2?
Thanks,
Graham
On Thu, 29 Aug 2013 07:26:40 -0400
Ahmed Fasih <wuzzyview(a)gmail.com> wrote:
> Since PyCUDA is just a wrapper to the CUDA C library (with >99.9%
> coverage), anything CUDA supports, PyCUDA should support. More directly,
> PyCUDA and K20 work fine for me.
I am running PyCuda on a debian6 computer with a GeForce Titan. Driver is 319.32 and Cuda 4.2.
My only problem is when I try to use scikit.cuda (for CuFFT) where sm_35 is not recognized.
The issue is probably located around the old version of cuda.
If you stick to pure PyCuda, it runs fine.
--
Jérôme Kieffer
On-Line Data analysis / Software Group
ISDD / ESRF
tel +33 476 882 445
I've just tested on GeForce 460 with CUDA 5.5 and drivers 325.15,
and your example worked without any problems - kernel was stopped
at doublify.
I assume that you have installed all programs (drivers, CUDA, PyCUDA)
from Debian repositories, or have you downloaded, compiled and
installed something yourself?
What hardware are you running it on?
And, which might be the stupid question, were you running
this from X or from console? Anything card below Kepler with Compute
Capabilities 3.5 cannot at the same time be used to display X
and to debug. So if you have only one card which you use for
displaying your X session on monitor, you cannot use the same
card for debugging. This might explain problems you described.
Best regards.
--
Tomasz Rybak GPG/PGP key ID: 2AD5 9860
Fingerprint A481 824E 7DD3 9C0E C40A 488E C654 FB33 2AD5 9860
http://member.acm.org/~tomaszrybak