Okay, with a tiny tweak to compiler.compile, I have UB pycuda working in both 64 and 32-bit. All I did was tell compile() to add '-m64' to options if it detects 64-bit mode, in the same way as Bryan's trick.
I pushed a branch with the patch to my GitHub: http://github.com/minrk/pycuda, as well as a siteconf that works for the build. There are still a few failures in test_gpuarray for 64-bit, but I don't know what causes them. On Mon, Sep 20, 2010 at 11:30, Art <grenan...@gmail.com> wrote: > > On Mon, Sep 20, 2010 at 8:34 AM, Bryan Catanzaro < > catan...@eecs.berkeley.edu> wrote: > >> I think it should be changed to check to see if the Python interpreter is >> currently running in 32 bit mode, and then compile to match: >> >> if 'darwin' in sys.platform and sys.maxint == 2147483647: >> # The Python interpreter is running in 32 bit mode on OS X >> if "-arch" not in conf["CXXFLAGS"]: >> conf["CXXFLAGS"].extend(['-arch', 'i386', '-m32']) >> if "-arch" not in conf["LDFLAGS"]: >> conf["LDFLAGS"].extend(['-arch', 'i386', '-m32']) >> >> Some people (myself included) have to run Python in 32-bit mode on 64-bit >> OS X for various compatibility reasons (currently including libcudart.dylib, >> which is only shipped as a 32-bit library). Since the Python which Apple >> ships is compiled as a fat binary with both 32 and 64 bit versions, we can't >> know a priori what the right compiler flags are. >> >> - bryan > > > I have driver version 3.1.14 and: > > $ file /usr/local/cuda/lib/libcudart.dylib > /usr/local/cuda/lib/libcudart.dylib: Mach-O universal binary with 2 > architectures > /usr/local/cuda/lib/libcudart.dylib (for architecture x86_64): Mach-O > 64-bit dynamically linked shared library x86_64 > /usr/local/cuda/lib/libcudart.dylib (for architecture i386): Mach-O > dynamically linked shared library i386 > > Doesn't that mean it's UB? > You are right, that's UB, I guess the change was made at 3.1, not 3.2. In 3.0, they introduced UB for libcuda, but left all other libraries as i386. > I can build and test cudamat [1] (which uses ctypes to call libcudart and > libcublas) fine in 64-bit macports python though I haven't otherwise used > it. I had to make the following small change in it's Makefile: > > nvcc -O -m 64 -L/usr/local/cuda/lib --ptxas-options=-v --compiler-options > '-fPIC' -o libcudamat.so --shared cudamat.cu cudamat_kernels.cu -lcublas > > from: > > nvcc -O --ptxas-options=-v --compiler-options '-fPIC' -o libcudamat.so > --shared cudamat.cu cudamat_kernels.cu -lcublas > > I built pycuda as 64-bit and changed pycuda/compiler.py to pass --machine > 64 to nvcc and got examples/demo.py to run but the other examples and tests > had failures and would eventually hang my machine. I don't know enough to > fix this myself but I can try suggestions. Would using 3.2RC make a > difference? > If the rest of libraries are UB, as cudart is at 3.1, then 3.2 shouldn't make a difference from 3.1.x, I just knew that the switch was somewhere between 3.0 and 3.2, and it appears to have been at 3.1. -MinRK > > [1] http://code.google.com/p/cudamat/ > > cheers, > art > > > _______________________________________________ > PyCUDA mailing list > PyCUDA@tiker.net > http://lists.tiker.net/listinfo/pycuda > >
_______________________________________________ PyCUDA mailing list PyCUDA@tiker.net http://lists.tiker.net/listinfo/pycuda
