headers
Peter Rösch | 1 Feb 18:28
Picon
Favicon

Re: Error with uint32

> 
> I'm as confused as you. Can you go up the call stack and see who made
> that dtype, and how?
> 
> Andreas
> 
> 
after updating to pycuda-2011.2.2 and pyopencl-2011.2 the message described 
by Thomas turned up on my Debian squeeze boxes (32 and 64 bit):
cuda 4.1
python 2.6.6
numpy 1.4.1

Finally, the pycuda and pyopencl examples run on my systems after modifying
the files 
pycuda-2011.2.2/pycuda/compyte/dtypes.py
and
pyopencl-2011.2/pyopencl/compyte/dtypes.py
such that strings are used as keys in the dictionaries.

In _fill_dtype_registry I replaced

register_dtype(np.bool, "bool")
register_dtype(np.uint8, "unsigned char")
# ... and so on
register_dtype(np.float64, "double")

with

register_dtype("bool", "bool")
(Continue reading)

Permalink | Reply | 2 comments |
headers
Thomas Wiecki | 1 Feb 20:55
Favicon

Re: Error with uint32

Hi Peter,

this has been fixed (or rather, worked around at) a little bit more
cleanly in the version in the git repo to which you might want to
upgrade to.

Thomas

On Wed, Feb 1, 2012 at 12:28 PM, Peter Rösch
<Peter.Roesch@...> wrote:
>>
>> I'm as confused as you. Can you go up the call stack and see who made
>> that dtype, and how?
>>
>> Andreas
>>
>>
> after updating to pycuda-2011.2.2 and pyopencl-2011.2 the message described
> by Thomas turned up on my Debian squeeze boxes (32 and 64 bit):
> cuda 4.1
> python 2.6.6
> numpy 1.4.1
>
> Finally, the pycuda and pyopencl examples run on my systems after modifying
> the files
> pycuda-2011.2.2/pycuda/compyte/dtypes.py
> and
> pyopencl-2011.2/pyopencl/compyte/dtypes.py
> such that strings are used as keys in the dictionaries.
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Peter Roesch | 2 Feb 00:29
Picon
Favicon

Re: Error with uint32

Hi Thomas,

thanks a lot for your help. The upgrade you suggested resolved the
problem.

Peter

On Wed, Feb 01, 2012 at 02:55:21PM -0500, Thomas Wiecki wrote:
> Hi Peter,
> 
> this has been fixed (or rather, worked around at) a little bit more
> cleanly in the version in the git repo to which you might want to
> upgrade to.
> 
> Thomas
> 
> On Wed, Feb 1, 2012 at 12:28 PM, Peter Rösch
> <Peter.Roesch@...> wrote:
> >>
> >> I'm as confused as you. Can you go up the call stack and see who made
> >> that dtype, and how?
> >>
> >> Andreas
> >>
> >>
> > after updating to pycuda-2011.2.2 and pyopencl-2011.2 the message described
> > by Thomas turned up on my Debian squeeze boxes (32 and 64 bit):
> > cuda 4.1
> > python 2.6.6
> > numpy 1.4.1
(Continue reading)

Permalink | Reply | 0 comments |
headers
Igor | 2 Feb 10:05
Picon

exceptions.ImportError: DLL load failed

I just upgraded the driver, toolkit and SDK to CUDA 4.1 (uninstalling
CUDA 4.0 toolkit and SDK first), PyCUDA stopped working. Upgraded also
PyCUDA by installing pycuda-2011.2.2.win32-py2.7.‌exe,  same error
message as below, right at the first line of demo.py "import
pycuda.driver as cuda" or "from pycuda._driver import *". Restarted,
no change. I must have forgotten some important step that I should
re-do to get my set-up working again?

Message	File Name	Line	Position	
Traceback				
    <module>	W:\Programming\CUDA\PyCUDA\pycuda-2011.2.2\examples\demo.py	3		
    <module>	C:\Python27\lib\site-packages\pycuda\driver.py	2		
exceptions.ImportError: DLL load failed: The specified module could
not be found.

_______________________________________________
PyCUDA mailing list
PyCUDA <at> tiker.net
http://lists.tiker.net/listinfo/pycuda
Permalink | Reply | 4 comments |
headers
Jonathan WRIGHT | 2 Feb 10:46
Picon
Picon

Re: exceptions.ImportError: DLL load failed

Where do you get your binaries from? The ones from Christoph Gohlke 
require CUDA 4.0, but you have 4.1. I never got a reply on this message 
about building on windows x64 when I had 3.2:

http://thread.gmane.org/gmane.comp.python.cuda/2516

If that procedure also works for you then maybe we should update the 
wiki? You should just need the 2008 express edition compiler and not the 
SDK for 64-bit. I'm nervous about the "tss" issue which I did not 
understand.

Cheers

Jon

On 02/02/2012 10:05, Igor wrote:
> I just upgraded the driver, toolkit and SDK to CUDA 4.1 (uninstalling
> CUDA 4.0 toolkit and SDK first), PyCUDA stopped working. Upgraded also
> PyCUDA by installing pycuda-2011.2.2.win32-py2.7.‌exe,  same error
> message as below, right at the first line of demo.py "import
> pycuda.driver as cuda" or "from pycuda._driver import *". Restarted,
> no change. I must have forgotten some important step that I should
> re-do to get my set-up working again?
>
> Message	File Name	Line	Position	
> Traceback				
>      <module>	W:\Programming\CUDA\PyCUDA\pycuda-2011.2.2\examples\demo.py	3		
>      <module>	C:\Python27\lib\site-packages\pycuda\driver.py	2		
> exceptions.ImportError: DLL load failed: The specified module could
> not be found.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Igor | 2 Feb 12:39
Picon

Re: exceptions.ImportError: DLL load failed

Yes, the binary is from Christoph Gohlke. If nothing changed in my
set-up except CUDA from 4 to 4.1 how do I patch pyCUDA to find the new
CUDA driver, as I guess that's the problem. I'm not quite sure why we
talk about Visual Studio... I have it installed, of course, but I
don't understand why it's still needed.

On Thu, Feb 2, 2012 at 10:46 PM, Jonathan WRIGHT <wright <at> esrf.fr> wrote:
> Where do you get your binaries from? The ones from Christoph Gohlke require
> CUDA 4.0, but you have 4.1. I never got a reply on this message about
> building on windows x64 when I had 3.2:
>
> http://thread.gmane.org/gmane.comp.python.cuda/2516
>
> If that procedure also works for you then maybe we should update the wiki?
> You should just need the 2008 express edition compiler and not the SDK for
> 64-bit. I'm nervous about the "tss" issue which I did not understand.
>
> Cheers
>
> Jon
>
>
> On 02/02/2012 10:05, Igor wrote:
>>
>> I just upgraded the driver, toolkit and SDK to CUDA 4.1 (uninstalling
>> CUDA 4.0 toolkit and SDK first), PyCUDA stopped working. Upgraded also
>> PyCUDA by installing pycuda-2011.2.2.win32-py2.7.‌exe,  same error
>> message as below, right at the first line of demo.py "import
>> pycuda.driver as cuda" or "from pycuda._driver import *". Restarted,
>> no change. I must have forgotten some important step that I should
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jonathan WRIGHT | 2 Feb 14:05
Picon
Picon

Re: exceptions.ImportError: DLL load failed

The binary _driver.pyd file is a windows dll and it is linked to dlls 
with specific versions which come from the cuda toolkit. A change of 
CUDA versions means you (or someone) needs to recompile it before it 
will work for CUDA 4.1.

The problem is that pycuda is written in C++ and has to be recompiled 
from the C++ source code to get binaries to match your new CUDA dlls. 
Patching is only needed if there is some problem when you try to build 
it or run the unit tests.

Best

Jon

On 02/02/2012 12:39, Igor wrote:
> Yes, the binary is from Christoph Gohlke. If nothing changed in my
> set-up except CUDA from 4 to 4.1 how do I patch pyCUDA to find the new
> CUDA driver, as I guess that's the problem. I'm not quite sure why we
> talk about Visual Studio... I have it installed, of course, but I
> don't understand why it's still needed.
>
>
> On Thu, Feb 2, 2012 at 10:46 PM, Jonathan WRIGHT<wright <at> esrf.fr>  wrote:
>> Where do you get your binaries from? The ones from Christoph Gohlke require
>> CUDA 4.0, but you have 4.1. I never got a reply on this message about
>> building on windows x64 when I had 3.2:
>>
>> http://thread.gmane.org/gmane.comp.python.cuda/2516
>>
>> If that procedure also works for you then maybe we should update the wiki?
(Continue reading)

Permalink | Reply | 1 comment |
headers
David Eigen | 2 Feb 20:49
Picon

gpu memory leak when gc runs in another thread

Hi,

I ran into a gpu memory leak that appears to happen when gc frees GPUArrays that were created in a thread other
than the one gc is running in.  I did not see a github issue tracking this.  Is this a known issue that others
have run into?  I'm using pycuda 2011.2.2 with python 2.6.7.

This happens when gc frees a DeviceAllocation that had been created in another thread.  Since there are no
refs to it, it is indeed freed, and the destructor tries to free the corresponding CUdeviceptr.  However,
the following lines cause mem_free not to be called: the scoped_context_activation checks that the
running thread matches the context's thread; since it doesn't, it throws an exception, which is silently
caught in CUDAPP_CATCH_CLEANUP_ON_DEAD_CONTEXT:

class device_allocation ...
      void free()
      {
        if (m_valid)
        {
          try
          {
            scoped_context_activation ca(get_context());
            mem_free(m_devptr);
          }
          CUDAPP_CATCH_CLEANUP_ON_DEAD_CONTEXT(device_allocation);

I was wondering how to go about fixing or working with this, or if anyone has any advice?

Thanks,
David
(Continue reading)

Permalink | Reply | 2 comments |
headers
Andreas Kloeckner | 2 Feb 22:56

Re: gpu memory leak when gc runs in another thread

On Thu, 2 Feb 2012 14:49:32 -0500, David Eigen <deigen@...> wrote:
> Hi,
> 
> I ran into a gpu memory leak that appears to happen when gc frees GPUArrays that were created in a thread
other than the one gc is running in.  I did not see a github issue tracking this.  Is this a known issue that
others have run into?  I'm using pycuda 2011.2.2 with python 2.6.7.
> 
> This happens when gc frees a DeviceAllocation that had been created in another thread.  Since there are no
refs to it, it is indeed freed, and the destructor tries to free the corresponding CUdeviceptr.  However,
the following lines cause mem_free not to be called: the scoped_context_activation checks that the
running thread matches the context's thread; since it doesn't, it throws an exception, which is silently
caught in CUDAPP_CATCH_CLEANUP_ON_DEAD_CONTEXT:
> 
> class device_allocation ...
>       void free()
>       {
>         if (m_valid)
>         {
>           try
>           {
>             scoped_context_activation ca(get_context());
>             mem_free(m_devptr);
>           }
>           CUDAPP_CATCH_CLEANUP_ON_DEAD_CONTEXT(device_allocation);
> 
> I was wondering how to go about fixing or working with this, or if
> anyone has any advice?

OpenCL is a better API if you absolutely need threading, so using
PyOpenCL is one possible workaround. Using processes rather than threads
(Continue reading)

Permalink | Reply | 1 comment |
headers
Igor | 3 Feb 10:02
Picon

Re: exceptions.ImportError: DLL load failed

Thanks so much for the explanation. How did you know that Christoph
Gohlke's binary doesn't support CUDA 4.1? How do we know when/if he's
going to update it? I'm hjesitating to build it myself as there may be
further problems. I'd rather wait.

On Fri, Feb 3, 2012 at 2:05 AM, Jonathan WRIGHT <wright <at> esrf.fr> wrote:
> The binary _driver.pyd file is a windows dll and it is linked to dlls with
> specific versions which come from the cuda toolkit. A change of CUDA
> versions means you (or someone) needs to recompile it before it will work
> for CUDA 4.1.
>
> The problem is that pycuda is written in C++ and has to be recompiled from
> the C++ source code to get binaries to match your new CUDA dlls. Patching is
> only needed if there is some problem when you try to build it or run the
> unit tests.
>
> Best
>
> Jon
>
>
>
>
> On 02/02/2012 12:39, Igor wrote:
>>
>> Yes, the binary is from Christoph Gohlke. If nothing changed in my
>> set-up except CUDA from 4 to 4.1 how do I patch pyCUDA to find the new
>> CUDA driver, as I guess that's the problem. I'm not quite sure why we
>> talk about Visual Studio... I have it installed, of course, but I
>> don't understand why it's still needed.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane