[PyCUDA] Re: PyCUDA OpenGL Build for Windows 10.

2020-03-01 Thread Fabio da Silva
 Ok,
the error from the previous message is because, on line 249, the argument of 
glutCreateWindow has to be b"PyCuda GL Interop Example" (notice the b before 
the ") instead of "PyCuda GL Interop Example". After that, there was an issue 
related to the cl.exe and nvcc.exe compilers for MSVC and Nvidia not being in 
the system path. Once all that was corrected, I was able to see the teapot spin 
around with not response to the keys "a" and "e". I am assuming CUDA is working 
because the speed of the output matches that of the MSVC interop .exe file. 
Still, in the console where I ran the example, I got:
Hit ESC key to quit, 'a' to toggle animation, and 'e' to toggle cudaUnable to 
load numpy_formathandler accelerator from 
OpenGL_acceleratepycuda-opengl-interop.py:41: DeprecationWarning: buffer_object 
has been deprecated since CUDA 3.0 and PyCUDA 2011.1.  pycuda_source_pbo = 
cuda_gl.BufferObject(long(source_pbo))pycuda-opengl-interop.py:46: 
DeprecationWarning: buffer_object has been deprecated since CUDA 3.0 and PyCUDA 
2011.1.  pycuda_dest_pbo = 
cuda_gl.BufferObject(long(dest_pbo))pycuda-opengl-interop.py:100: 
DeprecationWarning: time.clock has been deprecated in Python 3.3 and will be 
removed from Python 3.8: use time.perf_counter or time.process_time instead  if 
((time.clock () * 1000.0) - time_of_last_titleupdate >= 
1000.):pycuda-opengl-interop.py:105: DeprecationWarning: time.clock has been 
deprecated in Python 3.3 and will be removed from Python 3.8: use 
time.perf_counter or time.process_time instead  time_of_last_titleupdate = 
time.clock () * 1000.0pycuda-opengl-interop.py:184: DeprecationWarning: 
buffer_object has been deprecated since CUDA 3.0 and PyCUDA 2011.1.  
pycuda_source_pbo = 
cuda_gl.BufferObject(long(source_pbo))pycuda-opengl-interop.py:150: 
DeprecationWarning: map_buffer_object has been deprecated since CUDA 3.0 and 
PyCUDA 2011.1.  source_mapping = 
pycuda_source_pbo.map()pycuda-opengl-interop.py:150: DeprecationWarning: 
buffer_object_mapping has been deprecated since CUDA 3.0 and PyCUDA 2011.1.  
source_mapping = pycuda_source_pbo.map()pycuda-opengl-interop.py:151: 
DeprecationWarning: map_buffer_object has been deprecated since CUDA 3.0 and 
PyCUDA 2011.1.  dest_mapping   = 
pycuda_dest_pbo.map()pycuda-opengl-interop.py:151: DeprecationWarning: 
buffer_object_mapping has been deprecated since CUDA 3.0 and PyCUDA 2011.1.  
dest_mapping   = pycuda_dest_pbo.map()
More due diligence, but I can now focus solely on the Python code.
Hope this helps others with the same issue.
Thanks, Andreas, again for the critical pointers to get me to move along with 
this project.Fabio.On Sunday, March 1, 2020, 04:29:05 PM MST, Fabio da 
Silva  wrote:  
 
 Ok, I got it to work. Basically, the new build resides in a subfolder 
named:build\lib.win-amd64-3.7

I then copied the pycuda folder and placed in my Miniconda lib 
folder:Miniconda3\Lib\site-packages

I had to rename the current pycuda folder with pycuda.old to make sure I could 
revert.
When I do import pycuda.gl, it works. So I went ahead and downloaded the 
interoperability example fromPyCuda/Examples/GlInterop - Andreas Klöckner's wiki
and ran it! There were some print usage that followed the Python 2.7 format 
that I converted to Python 3.7 by putting the argument in parenthesis. I reran 
and the output was:
Hit ESC key to quit, 'a' to toggle animation, and 'e' to toggle cudaTraceback 
(most recent call last):  File "pycuda-opengl-interop.py", line 292, in 
    main()  File "pycuda-opengl-interop.py", line 249, in main    
window = glutCreateWindow("PyCuda GL Interop Example")  File 
"C:\Users\fcss\Miniconda3\lib\site-packages\OpenGL\GLUT\special.py", line 73, 
in glutCreateWindow    return __glutCreateWindowWithExit(title, 
_exitfunc)ctypes.ArgumentError: argument 1: : wrong type
I think this output may belong to another list (I haven't done my due diligence 
yet), but if anyone knows about it and want to help, it will always be 
appreciated.
Cordially,Fabio.




   On Tuesday, February 25, 2020, 11:33:55 AM MST, Andreas Kloeckner 
 wrote:  
 
 Fabio da Silva  writes:

> Good morning,
> I was wondering if there are any binaries for OpenGL enabled PyCUDA
> for Windows 10. My understanding (thanks, Andreas) is that it I will
> probably need to build it on my own. Since I never did that, I went
> online and found some resources here
> (https://stackoverflow.com/questions/19634073/pip-install-pycuda-on-windows)
> with the source code from here
> (https://files.pythonhosted.org/packages/5e/3f/5658c38579b41866ba21ee1b5020b8225cec86fe717e4b1c5c972de0a33c/pycuda-2019.1.2.tar.gz).
>  Specifically:1. Downloaded
> the source code from pythonhosted and untarred it.2. On the main
> folder I ran:>> python configure.py3. Then I went to siteconf.py and
> enabled OpenGL on line 9:CUDA_ENABLE_GL = True4. Finally I ran the
> commands:>> python setup.py build>> python setup.py install 

> After that, I tried to open PyCUDA in an IPython window a

[PyCUDA] Re: PyCUDA OpenGL Build for Windows 10.

2020-03-01 Thread Fabio da Silva
Ok, I got it to work. Basically, the new build resides in a subfolder 
named:build\lib.win-amd64-3.7

I then copied the pycuda folder and placed in my Miniconda lib 
folder:Miniconda3\Lib\site-packages

I had to rename the current pycuda folder with pycuda.old to make sure I could 
revert.
When I do import pycuda.gl, it works. So I went ahead and downloaded the 
interoperability example fromPyCuda/Examples/GlInterop - Andreas Klöckner's wiki
and ran it! There were some print usage that followed the Python 2.7 format 
that I converted to Python 3.7 by putting the argument in parenthesis. I reran 
and the output was:
Hit ESC key to quit, 'a' to toggle animation, and 'e' to toggle cudaTraceback 
(most recent call last):  File "pycuda-opengl-interop.py", line 292, in 
    main()  File "pycuda-opengl-interop.py", line 249, in main    
window = glutCreateWindow("PyCuda GL Interop Example")  File 
"C:\Users\fcss\Miniconda3\lib\site-packages\OpenGL\GLUT\special.py", line 73, 
in glutCreateWindow    return __glutCreateWindowWithExit(title, 
_exitfunc)ctypes.ArgumentError: argument 1: : wrong type
I think this output may belong to another list (I haven't done my due diligence 
yet), but if anyone knows about it and want to help, it will always be 
appreciated.
Cordially,Fabio.




   On Tuesday, February 25, 2020, 11:33:55 AM MST, Andreas Kloeckner 
 wrote:  
 
 Fabio da Silva  writes:

> Good morning,
> I was wondering if there are any binaries for OpenGL enabled PyCUDA
> for Windows 10. My understanding (thanks, Andreas) is that it I will
> probably need to build it on my own. Since I never did that, I went
> online and found some resources here
> (https://stackoverflow.com/questions/19634073/pip-install-pycuda-on-windows)
> with the source code from here
> (https://files.pythonhosted.org/packages/5e/3f/5658c38579b41866ba21ee1b5020b8225cec86fe717e4b1c5c972de0a33c/pycuda-2019.1.2.tar.gz).
>  Specifically:1. Downloaded
> the source code from pythonhosted and untarred it.2. On the main
> folder I ran:>> python configure.py3. Then I went to siteconf.py and
> enabled OpenGL on line 9:CUDA_ENABLE_GL = True4. Finally I ran the
> commands:>> python setup.py build>> python setup.py install 

> After that, I tried to open PyCUDA in an IPython window and
> got:ModuleNotFoudError: No module named 'pycuda._driver'And obviously
> no pycuda.gl either.

If your build from above completed, then you should have PyCUDA
installed *somewhere*. This somewhere may just not be the same Python
interpreter as what your Jupyter notebook uses. You can find out where
these interpreters live by examining sys.path (from both the notebook
and the Python prompt for the Python that you used to build/install)

HTH,
Andreas___
PyCUDA mailing list -- pycuda@tiker.net
To unsubscribe send an email to pycuda-le...@tiker.net
  ___
PyCUDA mailing list -- pycuda@tiker.net
To unsubscribe send an email to pycuda-le...@tiker.net


[PyCUDA] Re: PyCUDA OpenGL Build for Windows 10.

2020-02-25 Thread Andreas Kloeckner
Fabio da Silva  writes:

> Good morning,
> I was wondering if there are any binaries for OpenGL enabled PyCUDA
> for Windows 10. My understanding (thanks, Andreas) is that it I will
> probably need to build it on my own. Since I never did that, I went
> online and found some resources here
> (https://stackoverflow.com/questions/19634073/pip-install-pycuda-on-windows)
> with the source code from here
> (https://files.pythonhosted.org/packages/5e/3f/5658c38579b41866ba21ee1b5020b8225cec86fe717e4b1c5c972de0a33c/pycuda-2019.1.2.tar.gz).
>  Specifically:1. Downloaded
> the source code from pythonhosted and untarred it.2. On the main
> folder I ran:>> python configure.py3. Then I went to siteconf.py and
> enabled OpenGL on line 9:CUDA_ENABLE_GL = True4. Finally I ran the
> commands:>> python setup.py build>> python setup.py install 

> After that, I tried to open PyCUDA in an IPython window and
> got:ModuleNotFoudError: No module named 'pycuda._driver'And obviously
> no pycuda.gl either.

If your build from above completed, then you should have PyCUDA
installed *somewhere*. This somewhere may just not be the same Python
interpreter as what your Jupyter notebook uses. You can find out where
these interpreters live by examining sys.path (from both the notebook
and the Python prompt for the Python that you used to build/install)

HTH,
Andreas


signature.asc
Description: PGP signature
___
PyCUDA mailing list -- pycuda@tiker.net
To unsubscribe send an email to pycuda-le...@tiker.net


Re: [PyCUDA] OpenGL missing feature

2011-03-09 Thread Andreas Kloeckner
Hi Tomasz,

On Tue, 08 Mar 2011 22:10:37 +0100, "=?UTF-8?B?VG9tYXN6IFJ5YmFr?=" 
 wrote:
> Hello.
> Some time ago I have sent new-style OpenGL wrapper. Don't worry, it works.
> But recently I have been working on new program and noticed that new-style
> OpenGL wrapper requires calling separate functions when mapping buffer and
> surface objects. When mapping ordinary textures, they are treated as
> surfaces, when texture is backed by a buffer, one can just map buffer -
> and this is how I missed this function during testing functionality of
> wrapper. I attach the patch that adds needed function (it also removes old
> comment about missing feature).
> Few problems with current situation (even after applyting this patch):
> 1. Programmer needs to remember which mapping contains surface and which
> contains buffer. Would it be better to create separete classes that
> would deal with those cases separately? Even if so, could you Andreas
> apply this patch (to have fully working OpenGL wrapper) and deal with
> changes in API later?

I don't see a big need. IIUC, the only difference would be who generates
the error message--the CUDA implementation or PyCUDA. And in this case,
I prefer letting CUDA do the complaining.

> 2. CUDA API returns CUarray. So far the only way of accessing it in PyCUDA
> is through GPUArray, but when attaching to CUarray GPUArray creates new
> object; we need ability to attach to existing CUarray without changing it.
> Sorry for missing this so far. The only explanation is that accessing bare 
> textures in CUDA
> is not used very often - especially as noone has complained about this 
> missing feature so far :-)

Applied (with minor fixes), thanks!

Andreas



pgpbHGygB6pxE.pgp
Description: PGP signature
___
PyCUDA mailing list
PyCUDA@tiker.net
http://lists.tiker.net/listinfo/pycuda


Re: [PyCUDA] OpenGL and new functions

2010-11-28 Thread Andreas Kloeckner
On Sat, 27 Nov 2010 23:20:40 +0100, Tomasz Rybak  wrote:
> I do not know how to force Boost::Python to allow
> for accepting optional argument for map(stream) function,
> so I changed documentation to say that stream is mandatory
> argument.

I made the change to make that argument optional.

> This patch also removes CUgraphicsMapResourceFlags from
> src/wrapper/wrap_cudadrv.cpp - it was generating warning
> seen above.

OK.

> I attach the patch that solves those problems.

Thanks, applied!

Andreas



pgp3I1Jgc97F2.pgp
Description: PGP signature
___
PyCUDA mailing list
PyCUDA@tiker.net
http://lists.tiker.net/listinfo/pycuda


Re: [PyCUDA] OpenGL and new functions

2010-11-27 Thread Tomasz Rybak
Dnia 2010-11-26, pią o godzinie 14:52 -0500, Andreas Kloeckner pisze:
> Hi Tomasz,
> 
> I've committed your patch, with a few changes.
> 
> git diff 69a355d0 master
> 
> will show you what I changed. Some comments below. I'd appreciate your
> feedback on my changes.
> 
> Thanks for your contribution,
> Andreas
> 

I like those changes, but there are still some problems.

The fist problem is that you have left old names in pycuda/gl/__init.py:

$ ./cuda.py
/usr/lib/pymodules/python2.6/pycuda/driver.py:2: RuntimeWarning:
to-Python converter for CUgraphicsMapResourceFlags_enum already
registered; second conversion method ignored.
  from pycuda._driver import *
Traceback (most recent call last):
  File "./cuda.py", line 13, in 
import pycuda.gl
  File "/usr/lib/pymodules/python2.6/pycuda/gl/__init__.py", line 8, in

map_flags = _drv.map_flags
AttributeError: 'module' object has no attribute 'map_flags'

$ ./cuda.py
/usr/lib/pymodules/python2.6/pycuda/driver.py:2: RuntimeWarning:
to-Python converter for CUgraphicsMapResourceFlags_enum already
registered; second conversion method ignored.
  from pycuda._driver import *
Traceback (most recent call last):
  File "./cuda.py", line 13, in 
import pycuda.gl
  File "/usr/lib/pymodules/python2.6/pycuda/gl/__init__.py", line 9, in

target_flags = _drv.target_flags
AttributeError: 'module' object has no attribute 'target_flags

The second problem is with the map function:

$ ./cuda.py
Traceback (most recent call last):
  File "./cuda.py", line 103, in paintGL
cuda_object = self.cuda_buffer.map()
Boost.Python.ArgumentError: Python argument types in
RegisteredObject.map(RegisteredBuffer)
did not match C++ signature:
map(boost::shared_ptr)

I do not know how to force Boost::Python to allow
for accepting optional argument for map(stream) function,
so I changed documentation to say that stream is mandatory
argument.

I attach the patch that solves those problems.

This patch also removes CUgraphicsMapResourceFlags from
src/wrapper/wrap_cudadrv.cpp - it was generating warning
seen above.


> On Wed, 24 Nov 2010 23:58:01 +0100, Tomasz Rybak  wrote:
> > Sending patch once again - it looks line not everyone received
> > previous email, and I got no feedback on patch.
> > 
> > -- 
> > Tomasz Rybak  GPG/PGP key ID: 2AD5 9860
> > Fingerprint A481 824E 7DD3 9C0E C40A  488E C654 FB33 2AD5 9860
> > http://member.acm.org/~tomaszrybak
> > diff --git a/doc/source/gl.rst b/doc/source/gl.rst
> > index e5d196f..6d7b42c 100644
> > --- a/doc/source/gl.rst
> > +++ b/doc/source/gl.rst
> > @@ -19,6 +19,8 @@ GL Interoperability
> >  
> >  .. warning ::
> >  
> > +This function is deprecated since CUDA 3.0 and PyCUDA 0.95.
> > +
> >  This will fail with a rather unhelpful error message if you don't 
> > already 
> >  have a GL context created and active.
> >  
> > @@ -33,11 +35,43 @@ GL Interoperability
> >  This will fail with a rather unhelpful error message if you don't 
> > already 
> >  have a GL context created and active.
> >  
> > +.. class :: map_flags
> > +
> > +Usage of OpenGL object from CUDA.
> > +
> > +.. attribute :: CU_GRAPHICS_MAP_RESOURCE_FLAGS_NONE
> > +
> > +Read and write access to mapped OpenGL object from CUDA code.
> > +
> > +.. attribute :: CU_GRAPHICS_MAP_RESOURCE_FLAGS_READ_ONLY
> > +
> > +Read only access to mapped OpenGL object from CUDA code.
> > +
> > +.. attribute :: CU_GRAPHICS_MAP_RESOURCE_FLAGS_WRITE_DISCARD
> > +
> > +Write only access to mapped OpenGL object from CUDA code. Reading
> > +is prohibited.
> 
> Changed/shortened names.

OK.

> 
> > +
> > +.. class :: map_targets
> > +
> > +Type of OpenGL Image object that is mapped to CUDA.
> > +
> > +.. attribute :: GL_TEXTURE_2D
> > +.. attribute :: GL_TEXTURE_RECTANGLE
> > +.. attribute :: GL_TEXTURE_CUBE_MAP
> > +.. attribute :: GL_TEXTURE_3D
> > +.. attribute :: GL_TEXTURE_2D_ARRAY
> > +.. attribute :: GL_RENDERBUFFER
> > +
> 
> I'd argue these are the GL wrapper's business, since they're defined in
> the GL header. Removed.
> 
> >  .. class :: BufferObject(bufobj)
> >  
> >  .. method :: unregister()
> >  .. method :: handle()
> >  .. method :: map()
> > +
> > +.. warning ::
> > +
> > +This class is deprecated since CUDA 3.0 and PyCUDA 0.95.
> >  
> 
> I've made a nice separate section for the old-style API in the docs, so
> no-one uses it by accident.

OK - makes sense.

> 
> >  .. class :: BufferObjectMapping
> >  
> > @@ -45,6 +79,33 @@ GL Interoperability
> >  .. method :: device_ptr()
> >  .. method :: size()
> >  
> > +.. warning ::
> > +
> > +This class is deprecated since CUDA 3.0 and PyCUDA 0.95.
> > +
> > +.. class :: RegisteredBuffer(bufobj, flags = 
> > CU_GRAPHICS_MAP_RESOURCE_FLAGS_NONE)
> > +
> > +  Object managing mapping of OpenGL buffers to CUDA. Cannot be used to
> > +  map images.
> > +
> > +.. 

Re: [PyCUDA] OpenGL and new functions

2010-11-26 Thread Andreas Kloeckner
Hi Tomasz,

I've committed your patch, with a few changes.

git diff 69a355d0 master

will show you what I changed. Some comments below. I'd appreciate your
feedback on my changes.

Thanks for your contribution,
Andreas

On Wed, 24 Nov 2010 23:58:01 +0100, Tomasz Rybak  wrote:
> Sending patch once again - it looks line not everyone received
> previous email, and I got no feedback on patch.
> 
> -- 
> Tomasz Rybak  GPG/PGP key ID: 2AD5 9860
> Fingerprint A481 824E 7DD3 9C0E C40A  488E C654 FB33 2AD5 9860
> http://member.acm.org/~tomaszrybak
> diff --git a/doc/source/gl.rst b/doc/source/gl.rst
> index e5d196f..6d7b42c 100644
> --- a/doc/source/gl.rst
> +++ b/doc/source/gl.rst
> @@ -19,6 +19,8 @@ GL Interoperability
>  
>  .. warning ::
>  
> +This function is deprecated since CUDA 3.0 and PyCUDA 0.95.
> +
>  This will fail with a rather unhelpful error message if you don't 
> already 
>  have a GL context created and active.
>  
> @@ -33,11 +35,43 @@ GL Interoperability
>  This will fail with a rather unhelpful error message if you don't 
> already 
>  have a GL context created and active.
>  
> +.. class :: map_flags
> +
> +Usage of OpenGL object from CUDA.
> +
> +.. attribute :: CU_GRAPHICS_MAP_RESOURCE_FLAGS_NONE
> +
> +Read and write access to mapped OpenGL object from CUDA code.
> +
> +.. attribute :: CU_GRAPHICS_MAP_RESOURCE_FLAGS_READ_ONLY
> +
> +Read only access to mapped OpenGL object from CUDA code.
> +
> +.. attribute :: CU_GRAPHICS_MAP_RESOURCE_FLAGS_WRITE_DISCARD
> +
> +Write only access to mapped OpenGL object from CUDA code. Reading
> +is prohibited.

Changed/shortened names.

> +
> +.. class :: map_targets
> +
> +Type of OpenGL Image object that is mapped to CUDA.
> +
> +.. attribute :: GL_TEXTURE_2D
> +.. attribute :: GL_TEXTURE_RECTANGLE
> +.. attribute :: GL_TEXTURE_CUBE_MAP
> +.. attribute :: GL_TEXTURE_3D
> +.. attribute :: GL_TEXTURE_2D_ARRAY
> +.. attribute :: GL_RENDERBUFFER
> +

I'd argue these are the GL wrapper's business, since they're defined in
the GL header. Removed.

>  .. class :: BufferObject(bufobj)
>  
>  .. method :: unregister()
>  .. method :: handle()
>  .. method :: map()
> +
> +.. warning ::
> +
> +This class is deprecated since CUDA 3.0 and PyCUDA 0.95.
>  

I've made a nice separate section for the old-style API in the docs, so
no-one uses it by accident.

>  .. class :: BufferObjectMapping
>  
> @@ -45,6 +79,33 @@ GL Interoperability
>  .. method :: device_ptr()
>  .. method :: size()
>  
> +.. warning ::
> +
> +This class is deprecated since CUDA 3.0 and PyCUDA 0.95.
> +
> +.. class :: RegisteredBuffer(bufobj, flags = 
> CU_GRAPHICS_MAP_RESOURCE_FLAGS_NONE)
> +
> +  Object managing mapping of OpenGL buffers to CUDA. Cannot be used to
> +  map images.
> +
> +.. method :: unregister()
> +.. method :: handle()
> +.. method :: map()
> +
> +.. class :: RegisteredImage(bufobj, target, flags = 
> CU_GRAPHICS_MAP_RESOURCE_FLAGS_NONE)
> +
> +  Object managing mapping of OpenGL textures and render buffers to CUDA.
> +
> +.. method :: unregister()
> +.. method :: handle()
> +.. method :: map()
> +
> +.. class :: RegisteredMapping
> +
> +.. method :: unmap()
> +.. method :: device_ptr()
> +.. method :: size()
> +

Renamed handle() -> gl_handle() for clarity. Added stream arguments to
map()/unmap(). Since Nvidia saw it fit to have a batch interface to
map/unmap, we might need one at some point, too.




pgp4C2Uxb0GNm.pgp
Description: PGP signature
___
PyCUDA mailing list
PyCUDA@tiker.net
http://lists.tiker.net/listinfo/pycuda


Re: [PyCUDA] OpenGL and new functions

2010-11-24 Thread Tomasz Rybak
Dnia 2010-11-13, sob o godzinie 21:55 +0100, Tomasz Rybak pisze:

> I have worked on patch.
> I have added comments to old functions/classes about deprecation.
> I have created 4 classes:
> registered_object - base class
> registered_buffer inheriting from registered_object - class for buffers
> registered_image inheriting from registered_object - class for textures
> registered_mapping - 
> 
> Function:
> map_regiestered_object - creates mapping for objects (buffers
> and images).
> 
> Data types
> map_flags - whether to map RO, RW, or Write Only
> map_targets - for textures
> 
> Please give some feedback.

Sending patch once again - it looks line not everyone received
previous email, and I got no feedback on patch.

-- 
Tomasz Rybak  GPG/PGP key ID: 2AD5 9860
Fingerprint A481 824E 7DD3 9C0E C40A  488E C654 FB33 2AD5 9860
http://member.acm.org/~tomaszrybak
diff --git a/doc/source/gl.rst b/doc/source/gl.rst
index e5d196f..6d7b42c 100644
--- a/doc/source/gl.rst
+++ b/doc/source/gl.rst
@@ -19,6 +19,8 @@ GL Interoperability
 
 .. warning ::
 
+This function is deprecated since CUDA 3.0 and PyCUDA 0.95.
+
 This will fail with a rather unhelpful error message if you don't already 
 have a GL context created and active.
 
@@ -33,11 +35,43 @@ GL Interoperability
 This will fail with a rather unhelpful error message if you don't already 
 have a GL context created and active.
 
+.. class :: map_flags
+
+Usage of OpenGL object from CUDA.
+
+.. attribute :: CU_GRAPHICS_MAP_RESOURCE_FLAGS_NONE
+
+Read and write access to mapped OpenGL object from CUDA code.
+
+.. attribute :: CU_GRAPHICS_MAP_RESOURCE_FLAGS_READ_ONLY
+
+Read only access to mapped OpenGL object from CUDA code.
+
+.. attribute :: CU_GRAPHICS_MAP_RESOURCE_FLAGS_WRITE_DISCARD
+
+Write only access to mapped OpenGL object from CUDA code. Reading
+is prohibited.
+
+.. class :: map_targets
+
+Type of OpenGL Image object that is mapped to CUDA.
+
+.. attribute :: GL_TEXTURE_2D
+.. attribute :: GL_TEXTURE_RECTANGLE
+.. attribute :: GL_TEXTURE_CUBE_MAP
+.. attribute :: GL_TEXTURE_3D
+.. attribute :: GL_TEXTURE_2D_ARRAY
+.. attribute :: GL_RENDERBUFFER
+
 .. class :: BufferObject(bufobj)
 
 .. method :: unregister()
 .. method :: handle()
 .. method :: map()
+
+.. warning ::
+
+This class is deprecated since CUDA 3.0 and PyCUDA 0.95.
 
 .. class :: BufferObjectMapping
 
@@ -45,6 +79,33 @@ GL Interoperability
 .. method :: device_ptr()
 .. method :: size()
 
+.. warning ::
+
+This class is deprecated since CUDA 3.0 and PyCUDA 0.95.
+
+.. class :: RegisteredBuffer(bufobj, flags = CU_GRAPHICS_MAP_RESOURCE_FLAGS_NONE)
+
+  Object managing mapping of OpenGL buffers to CUDA. Cannot be used to
+  map images.
+
+.. method :: unregister()
+.. method :: handle()
+.. method :: map()
+
+.. class :: RegisteredImage(bufobj, target, flags = CU_GRAPHICS_MAP_RESOURCE_FLAGS_NONE)
+
+  Object managing mapping of OpenGL textures and render buffers to CUDA.
+
+.. method :: unregister()
+.. method :: handle()
+.. method :: map()
+
+.. class :: RegisteredMapping
+
+.. method :: unmap()
+.. method :: device_ptr()
+.. method :: size()
+
 .. note ::
 
 See this `post `_ on the
diff --git a/pycuda/gl/__init__.py b/pycuda/gl/__init__.py
index a18b3d2..9d518a5 100644
--- a/pycuda/gl/__init__.py
+++ b/pycuda/gl/__init__.py
@@ -5,5 +5,10 @@ if not _drv.have_gl_ext():
 
 init = _drv.gl_init
 make_context = _drv.make_gl_context
+map_flags = _drv.map_flags
+target_flags = _drv.target_flags
 BufferObject = _drv.BufferObject
 BufferObjectMapping = _drv.BufferObjectMapping
+RegisteredBuffer = _drv.RegisteredBuffer
+RegisteredImage = _drv.RegisteredImage
+RegisteredMapping = _drv.RegisteredMapping
diff --git a/pycuda/gl/autoinit.py b/pycuda/gl/autoinit.py
index 9fb8e88..ab9cf22 100644
--- a/pycuda/gl/autoinit.py
+++ b/pycuda/gl/autoinit.py
@@ -5,7 +5,8 @@ import pycuda.tools
 cuda.init()
 assert cuda.Device.count() >= 1
 
-device = pycuda.tools.get_default_device()
+# TODO: get default device
+device = cuda.Device(0)
 context = cudagl.make_context(device)
 
 import atexit
diff --git a/src/cpp/cuda_gl.hpp b/src/cpp/cuda_gl.hpp
index df8d289..e633627 100644
--- a/src/cpp/cuda_gl.hpp
+++ b/src/cpp/cuda_gl.hpp
@@ -18,6 +18,8 @@ namespace cuda { namespace gl {
   void gl_init()
   {
 CUDAPP_CALL_GUARDED(cuGLInit, ());
+// Maybe use PyErr_WarnEx?
+std::cerr << "gl_init has been deprecated since CUDA 3.0 and PyCUDA 0.95" << std::endl;
   }
 
 
@@ -45,7 +47,10 @@ namespace cuda { namespace gl {
 public:
   buffer_object(GLuint handle)
 : m_handle(handle), m_valid(true)
-  { CUDAPP_CALL_GUARDED(cuGLRegisterBufferObject, (handle)); }
+  {
+CUDAPP_CALL_GUARDED(cuGLRegisterBufferObject, (handle));
+std

Re: [PyCUDA] OpenGL and new functions

2010-11-13 Thread Tomasz Rybak
Dnia 2010-11-01, pon o godzinie 22:17 +0100, Tomasz Rybak pisze:
[cut]
> > 
> > > 
> > > Function pycuda.tools.make_default_context contains
> > > repeated code checking for presence of CUDA device:
> > > 
> > > def make_default_context():
> > > ndevices = cuda.Device.count()
> > > if ndevices == 0:
> > > errmsg = "No CUDA enabled device found. Please check your
> > > installation."
> > > raise RuntimeError, errmsg
> > > 
> > > ndevices = cuda.Device.count()
> > > if ndevices == 0:
> > > raise RuntimeError("No CUDA enabled device found. "
> > > "Please check your installation.")
> > > 
> > > Why? Is that omission, or does this double checking serve
> > > some purpose?
> > 
> > Whoops. Fixed.
> > 
> 

I still cannot see this fix in public git repository - can you push it?


I have worked on patch.
I have added comments to old functions/classes about deprecation.
I have created 4 classes:
registered_object - base class
registered_buffer inheriting from registered_object - class for buffers
registered_image inheriting from registered_object - class for textures
registered_mapping - 

Function:
map_regiestered_object - creates mapping for objects (buffers
and images).

Data types
map_flags - whether to map RO, RW, or Write Only
map_targets - for textures

Please give some feedback.

-- 
Tomasz Rybak  GPG/PGP key ID: 2AD5 9860
Fingerprint A481 824E 7DD3 9C0E C40A  488E C654 FB33 2AD5 9860
http://member.acm.org/~tomaszrybak
diff --git a/doc/source/gl.rst b/doc/source/gl.rst
index e5d196f..4465600 100644
--- a/doc/source/gl.rst
+++ b/doc/source/gl.rst
@@ -19,6 +19,8 @@ GL Interoperability
 
 .. warning ::
 
+This function is deprecated since CUDA 3.0 and PyCUDA 0.95.
+
 This will fail with a rather unhelpful error message if you don't already 
 have a GL context created and active.
 
@@ -33,11 +35,43 @@ GL Interoperability
 This will fail with a rather unhelpful error message if you don't already 
 have a GL context created and active.
 
+.. class :: map_flags
+
+Usage of OpenGL object from CUDA.
+
+.. attribute :: CU_GRAPHICS_MAP_RESOURCE_FLAGS_NONE
+
+Read and write access to mapped OpenGL object from CUDA code.
+
+.. attribute :: CU_GRAPHICS_MAP_RESOURCE_FLAGS_READ_ONLY
+
+Read only access to mapped OpenGL object from CUDA code.
+
+.. attribute :: CU_GRAPHICS_MAP_RESOURCE_FLAGS_WRITE_DISCARD
+
+Write only access to mapped OpenGL object from CUDA code. Reading
+is prohibited.
+
+.. class :: map_targets
+
+Type of OpenGL Image object that is mapped to CUDA.
+
+.. attribute :: GL_TEXTURE_2D
+.. attribute :: GL_TEXTURE_RECTANGLE
+.. attribute :: GL_TEXTURE_CUBE_MAP
+.. attribute :: GL_TEXTURE_3D
+.. attribute :: GL_TEXTURE_2D_ARRAY
+.. attribute :: GL_RENDERBUFFER
+
 .. class :: BufferObject(bufobj)
 
 .. method :: unregister()
 .. method :: handle()
 .. method :: map()
+
+.. warning ::
+
+This class is deprecated since CUDA 3.0 and PyCUDA 0.95.
 
 .. class :: BufferObjectMapping
 
@@ -45,6 +79,33 @@ GL Interoperability
 .. method :: device_ptr()
 .. method :: size()
 
+.. warning ::
+
+This class is deprecated since CUDA 3.0 and PyCUDA 0.95.
+
+.. class :: RegisteredBuffer(bufobj, flags = CU_GRAPHICS_MAP_RESOURCE_FLAGS_NONE)
+
+  Object managing mapping of OpenGL buffers to CUDA. Cannot be used to
+  map images.
+
+.. method :: unregister()
+.. method :: handle()
+.. method :: map()
+
+.. class :: RegisteredImage(bufobj, target, flags = CU_GRAPHICS_MAP_RESOURCE_FLAGS_NONE)
+
+  Object managing mapping of OpenGL textures and render buffers to CUDA.
+
+.. method :: unregister()
+.. method :: handle()
+.. method :: map()
+
+.. class :: RegisteredMapping
+
+.. method :: unmap()
+.. method :: device_ptr()
+.. method :: size()
+
 .. note ::
 
 See this `post `_ on the
diff --git a/pycuda/gl/__init__.py b/pycuda/gl/__init__.py
index a18b3d2..9d518a5 100644
--- a/pycuda/gl/__init__.py
+++ b/pycuda/gl/__init__.py
@@ -5,5 +5,10 @@ if not _drv.have_gl_ext():
 
 init = _drv.gl_init
 make_context = _drv.make_gl_context
+map_flags = _drv.map_flags
+target_flags = _drv.target_flags
 BufferObject = _drv.BufferObject
 BufferObjectMapping = _drv.BufferObjectMapping
+RegisteredBuffer = _drv.RegisteredBuffer
+RegisteredImage = _drv.RegisteredImage
+RegisteredMapping = _drv.RegisteredMapping
diff --git a/pycuda/gl/autoinit.py b/pycuda/gl/autoinit.py
index 9fb8e88..ab9cf22 100644
--- a/pycuda/gl/autoinit.py
+++ b/pycuda/gl/autoinit.py
@@ -5,7 +5,8 @@ import pycuda.tools
 cuda.init()
 assert cuda.Device.count() >= 1
 
-device = pycuda.tools.get_default_device()
+# TODO: get default device
+device = cuda.Device(0)
 context = cudagl.make_context(device)
 
 import atexit
diff --git a/src/cpp/cuda_gl.hpp b/src/cpp/cuda_gl

Re: [PyCUDA] OpenGL and new functions

2010-11-01 Thread Tomasz Rybak
Dnia 2010-10-31, nie o godzinie 17:00 -0400, Andreas Kloeckner pisze:
> Hi Tomasz,
> 
> first of all, thanks for sending this patch! Much appreciated. Comments
> below.

No problem.
My responses and some rationale below.
I use Reference Manual 3.2rc, and all chapter numbers, etc. come from
this document.

Rationale.
In CUDA 3.0 NVIDIA introduced new function for mapping OpenGL
objects to CUDA, deprecating old functions. I believe that old
functions will remain in libraries for long time; they work,
and PyCUDA code using those bindings also works.
At the same time it is important that PyCUDA uses new functions,
as most code examples and discussions (e.g. on NVIDIA forums)
are using those new functions:

http://forums.nvidia.com/index.php?showtopic=183347
http://forums.nvidia.com/index.php?showtopic=184208
http://forums.nvidia.com/index.php?showtopic=183711

I know maintaining API compatibility of code is important,
and I am not proposing breaking PyCUDA.
At the same time I would like for the members of the list
to discuss their usage of OpenGL mappings, to know how to
deal with this transition.

> 
> On Fri, 29 Oct 2010 19:20:17 +0200, Tomasz Rybak  wrote:
> > The biggest problem is that IMO (I might be wrong - do
> > not know PyCUDA to such intimate details) it introduces
> > non-backward-compatible change.
> 
> Why do this? Why not introduce a new interface and leave the old one in
> place? That way, we can compile both interfaces as long as they're
> available, and it's up to the user which one to use. We shouldn't be in
> the business of imposing API use restrictions on PyCUDA users.

OK. This was rather intended as "proof of concept",
or to show intent. Besides - please come with better name
for new class?
We already have BufferObject in PyCUDA, and I would like
to avoid situation knows from Java ;-) (NewIO, NIO, ...) 

Is RegisteredBuffer/RegisteredImage OK as name for new classes?
Or better GraphicsBuffer/GraphicsImage?

> 
> > I have split BufferObject into two:
> > BufferObject responsible for buffers (VBO, etc.)
> > ImageObject responsible for textures, etc.
> > 
> > Previously BufferObject was responsible for both those
> > cases - now anyone who wants to use CUDA on images
> > must use ImageObject (which is API-breaking change).
> 
> Can you explain the reasoning for this split? A brief glance over the
> code didn't seem to reveal many differences. If nothing else, they
> should probably inherit from a common base that absorbs the shared code.

This comes from NVIDIA libraries.
According to CUDA Reference Manual 4.40.2 there are two functions
for mapping OpenGL objects into CUDA:
4.40.2.2 cuGraphicsGLRegisterBuffer
4.40.2.3 cuGraphicsGLRegisterImage
The former is for buffers, the latter for images, textures,
render buffers.
So this calls for two sets of classes - one for buffers,
one for images; their code would look very similarly,
but they would have different parameters for constructors
(like dimension of texture for ImageObject).

After creation of those mappings the rest of code is the same;
basically call
cuGraphicsMapResource
cuGraphicsResourceGetMappedPointer
...
cuGraphicsUnmapResources

I guess it should be possible to use only one mapper object/function
for both Image and Buffer mappings.



> 
> Also, I noticed that your use of cudaGrahpicsXXX flags with
> cuGrahpicsGLRegisterBuffer() is likely erroneous, as is visible in this
> bit of documentation. There are equivalent CU_... flags which we should
> use instead. See docs here (or in the header):
> 
> http://developer.download.nvidia.com/compute/cuda/3_0-Beta1/toolkit/docs/online/group__CUGL_ge148ed92fe0728be19c9281302b5922c.html
> 
> Also fishy: image_object, if it is different code, should probably be
> using cuGraphicsGLRegisterImage() (rather than ... Buffer()).

(mumbles about copy-paste inducing errors...)
Thanks - fixed.

> 
> > I also attach problem sample code (Qt+OpenGL+PyCUDA)
> > that uses new BufferObject.
> > I have checked and it works after applying my patch;
> > I only had to change initialisation to get program
> > using VBO running after applying my patch.
> 
> I still don't like that we need to change the init sequence--why is this
> necessary?

The only required thing is ensuring that GL-aware CUDA context
is created (cuGLCtxCreate) instead of ordinary context (cuCtxCreate).
This is done by import pycuda.gl.autoinit - but in my program
I had to call it in method of QGLWidget that initializes OpenGL,
not in the beginning of Python program.
If we leave "import pycuda.autoinit" and then add
"import pycuda.gl.autoinit" later the only disadvantage would be
two contexts - but I am not sure how CUDA would behave having
one ordinary and one GL-aware context.

There is of course problem with selecting GPU for usage - but I do
not know how to solve it for now.

> 
> > I have not checked ImageObject.
> > 
> > I have also started writing documentation for new pycuda.gl
> > functions.
> > 
> > I have removed gl_init as docum

Re: [PyCUDA] OpenGL and new functions

2010-10-31 Thread Andreas Kloeckner
Hi Tomasz,

first of all, thanks for sending this patch! Much appreciated. Comments
below.

On Fri, 29 Oct 2010 19:20:17 +0200, Tomasz Rybak  wrote:
> The biggest problem is that IMO (I might be wrong - do
> not know PyCUDA to such intimate details) it introduces
> non-backward-compatible change.

Why do this? Why not introduce a new interface and leave the old one in
place? That way, we can compile both interfaces as long as they're
available, and it's up to the user which one to use. We shouldn't be in
the business of imposing API use restrictions on PyCUDA users.

> I have split BufferObject into two:
> BufferObject responsible for buffers (VBO, etc.)
> ImageObject responsible for textures, etc.
> 
> Previously BufferObject was responsible for both those
> cases - now anyone who wants to use CUDA on images
> must use ImageObject (which is API-breaking change).

Can you explain the reasoning for this split? A brief glance over the
code didn't seem to reveal many differences. If nothing else, they
should probably inherit from a common base that absorbs the shared code.

Also, I noticed that your use of cudaGrahpicsXXX flags with
cuGrahpicsGLRegisterBuffer() is likely erroneous, as is visible in this
bit of documentation. There are equivalent CU_... flags which we should
use instead. See docs here (or in the header):

http://developer.download.nvidia.com/compute/cuda/3_0-Beta1/toolkit/docs/online/group__CUGL_ge148ed92fe0728be19c9281302b5922c.html

Also fishy: image_object, if it is different code, should probably be
using cuGraphicsGLRegisterImage() (rather than ... Buffer()).

> I also attach problem sample code (Qt+OpenGL+PyCUDA)
> that uses new BufferObject.
> I have checked and it works after applying my patch;
> I only had to change initialisation to get program
> using VBO running after applying my patch.

I still don't like that we need to change the init sequence--why is this
necessary?

> I have not checked ImageObject.
> 
> I have also started writing documentation for new pycuda.gl
> functions.
> 
> I have removed gl_init as documentation says that cuGLInit()
> is deprecated and is not doing anything (Reference 4.41.4.1).

Again, as above, we shouldn't be making API use decisions for our
users. I assume it did do something at some point in the past, so as
long as feasible we should still wrap it.

> Instead I have created gl_select_device; this function however
> must be called as the first (before all other CUDA functions),
> is cuda*, not cu* function, does not cooperate with
> CUDAPP_CALL_GUARDED - so I do not know what to do with it.
> I was not able to test it - I do not have setup with two devices.

As above, I don't like mixing in cuda* (run-time API) functionality with
cu* (driver API) functionality.

> Other problems:
> 
> Function pycuda.tools.get_default_device is depreciated,
> but pycuda.gl.autoinit uses it. I have changed autoinit
> to use Device(0), but it is not elegant and should be changed.



> 
> Function pycuda.tools.make_default_context contains
> repeated code checking for presence of CUDA device:
> 
> def make_default_context():
> ndevices = cuda.Device.count()
> if ndevices == 0:
> errmsg = "No CUDA enabled device found. Please check your
> installation."
> raise RuntimeError, errmsg
> 
> ndevices = cuda.Device.count()
> if ndevices == 0:
> raise RuntimeError("No CUDA enabled device found. "
> "Please check your installation.")
> 
> Why? Is that omission, or does this double checking serve
> some purpose?

Whoops. Fixed.

Andreas


pgpWcF3ZFrtNT.pgp
Description: PGP signature
___
PyCUDA mailing list
PyCUDA@tiker.net
http://lists.tiker.net/listinfo/pycuda


Re: [PyCUDA] OpenGl interop example

2010-03-03 Thread Andreas Klöckner
On Mittwoch 03 März 2010, Fabrizio Milo aka misto wrote:
> Errata corrige:
> 
> Seems it can be simply None, but not 0
> 
> >glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA,
> > w, h, 0, GL_RGBA, GL_UNSIGNED_BYTE, None)
> 
> Fabrizio

The wiki is the 'official' version of the examples, so you are able to
fix this yourself. Please go ahead!

Thanks,
Andreas


signature.asc
Description: This is a digitally signed message part.
___
PyCUDA mailing list
pyc...@host304.hostmonster.com
http://host304.hostmonster.com/mailman/listinfo/pycuda_tiker.net


Re: [PyCUDA] OpenGl interop example

2010-03-03 Thread Fabrizio Milo aka misto
Errata corrige:

Seems it can be simply None, but not 0

>    glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA,
>                 w, h, 0, GL_RGBA, GL_UNSIGNED_BYTE, None)

Fabrizio
--
Luck favors the prepared mind. (Pasteur)

___
PyCUDA mailing list
pyc...@host304.hostmonster.com
http://host304.hostmonster.com/mailman/listinfo/pycuda_tiker.net


Re: [PyCUDA] OpenGL

2009-08-15 Thread Gökhan Sever
Hello,

Testing the gl_interop.py example. See my specs:

[gse...@ccn release]$ ./deviceQuery
CUDA Device Query (Runtime API) version (CUDART static linking)
There is 1 device supporting CUDA

Device 0: "Quadro NVS 135M"
  CUDA Capability Major revision number: 1
  CUDA Capability Minor revision number: 1
  Total amount of global memory: 133496832 bytes
  Number of multiprocessors: 1
  Number of cores:   8
  Total amount of constant memory:   65536 bytes
  Total amount of shared memory per block:   16384 bytes
  Total number of registers available per block: 8192
  Warp size: 32
  Maximum number of threads per block:   512
  Maximum sizes of each dimension of a block:512 x 512 x 64
  Maximum sizes of each dimension of a grid: 65535 x 65535 x 1
  Maximum memory pitch:  262144 bytes
  Texture alignment: 256 bytes
  Clock rate:0.80 GHz
  Concurrent copy and execution: Yes
  Run time limit on kernels: Yes
  Integrated:No
  Support host page-locked memory mapping:   No
  Compute mode:  Default (multiple host
threads can use this device simultaneously)


Don't know what is going on really but after I hit "e" the FPS jumps from
~70 to ~1000 :)

Ahh just caught something, the window doesn't like to be maximized without
the CUDA mode on.

[gse...@ccn examples]$ python gl_interop.py
Hit ESC key to quit, 'a' to toggle animation, and 'e' to toggle cuda
Traceback (most recent call last):
  File "gl_interop.py", line 134, in display
process_image()
  File "gl_interop.py", line 181, in process_image
ctypes.c_void_p(0))
  File
"/usr/lib/python2.6/site-packages/PyOpenGL-3.0.0c1-py2.6.egg/OpenGL/error.py",
line 194, in glCheckError
baseOperation = baseOperation,
GLError: GLError(
err = 1282,
description = 'invalid operation',
baseOperation = glReadPixels,
cArguments = (
0,
0,
1440,
848,
GL_BGRA,
GL_UNSIGNED_BYTE,
c_void_p(None),
)
)


Maybe I need a newer PyOpenGL??

On Fri, Jul 31, 2009 at 8:12 AM, Michael Rule  wrote:

> gl_interop :
> is the expected behavior : opens a window which contains nothing (
> random garbage ), which then crashes on attempts to resize ?
>
> has anyone gotten closer to a functioning GL example ( e.g. preparing
> a vertex buffer in CUDA and then using it to render, say, a mesh, for
> accelerated computation of some simple physical simulation ? )
>
>
>
>
> On Tue, Jul 28, 2009 at 4:34 PM, Andreas
> Klöckner wrote:
> > On Dienstag 28 Juli 2009, you wrote:
> >> I would also like to try to experiment with pycuda openGL,
> >> how do you get the gl_interop example working ? I get the following
> message
> >> :
> >>
> >> "ImportError: PyCUDA was compiled without GL extension support"
> >>
> >> Is compiling pycuda with GL extension documented anywhere ?
> >
> > Add this to your siteconf.py:
> >
> > CUDA_ENABLE_GL = True
> >
> > Anddreas
> >
>
> ___
> PyCUDA mailing list
> PyCUDA@tiker.net
> http://tiker.net/mailman/listinfo/pycuda_tiker.net
>



-- 
Gökhan
___
PyCUDA mailing list
PyCUDA@tiker.net
http://tiker.net/mailman/listinfo/pycuda_tiker.net


Re: [PyCUDA] OpenGL

2009-07-31 Thread Michael Rule
gl_interop :
is the expected behavior : opens a window which contains nothing (
random garbage ), which then crashes on attempts to resize ?

has anyone gotten closer to a functioning GL example ( e.g. preparing
a vertex buffer in CUDA and then using it to render, say, a mesh, for
accelerated computation of some simple physical simulation ? )




On Tue, Jul 28, 2009 at 4:34 PM, Andreas
Klöckner wrote:
> On Dienstag 28 Juli 2009, you wrote:
>> I would also like to try to experiment with pycuda openGL,
>> how do you get the gl_interop example working ? I get the following message
>> :
>>
>> "ImportError: PyCUDA was compiled without GL extension support"
>>
>> Is compiling pycuda with GL extension documented anywhere ?
>
> Add this to your siteconf.py:
>
> CUDA_ENABLE_GL = True
>
> Anddreas
>

___
PyCUDA mailing list
PyCUDA@tiker.net
http://tiker.net/mailman/listinfo/pycuda_tiker.net


Re: [PyCUDA] OpenGL

2009-07-28 Thread Andreas Klöckner
On Dienstag 28 Juli 2009, you wrote:
> I would also like to try to experiment with pycuda openGL,
> how do you get the gl_interop example working ? I get the following message
> :
>
> "ImportError: PyCUDA was compiled without GL extension support"
>
> Is compiling pycuda with GL extension documented anywhere ?

Add this to your siteconf.py:

CUDA_ENABLE_GL = True

Anddreas


signature.asc
Description: This is a digitally signed message part.
___
PyCUDA mailing list
PyCUDA@tiker.net
http://tiker.net/mailman/listinfo/pycuda_tiker.net


Re: [PyCUDA] OpenGL

2009-07-28 Thread Michael Rule
I would also like to try to experiment with pycuda openGL,
how do you get the gl_interop example working ? I get the following message :

"ImportError: PyCUDA was compiled without GL extension support"

Is compiling pycuda with GL extension documented anywhere ?

-- mrule.



On Thu, Jul 9, 2009 at 10:48 PM, Andreas
Klöckner wrote:
> On Donnerstag 09 Juli 2009, Chris Heuser wrote:
>> Hey everyone,
>>
>> 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
>> insight?
>
> I feel like we're close, but not quite there. What we have so far is in git
> under examples/gl_interop.py. That brings up a window, apparently does some
> processing, and doesn't crash--at least for me.
>
> Peter?
>
> Andreas
>
> ___
> PyCUDA mailing list
> PyCUDA@tiker.net
> http://tiker.net/mailman/listinfo/pycuda_tiker.net
>
>

___
PyCUDA mailing list
PyCUDA@tiker.net
http://tiker.net/mailman/listinfo/pycuda_tiker.net


Re: [PyCUDA] OpenGL

2009-07-09 Thread Andreas Klöckner
On Donnerstag 09 Juli 2009, Chris Heuser wrote:
> Hey everyone,
>
> 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
> insight?

I feel like we're close, but not quite there. What we have so far is in git 
under examples/gl_interop.py. That brings up a window, apparently does some 
processing, and doesn't crash--at least for me.

Peter?

Andreas


signature.asc
Description: This is a digitally signed message part.
___
PyCUDA mailing list
PyCUDA@tiker.net
http://tiker.net/mailman/listinfo/pycuda_tiker.net


Re: [PyCUDA] OpenGL interop woes... help!

2009-06-28 Thread Andreas Klöckner
Hi Peter,

sorry for the delay. I finally found some time to look at this.

On Freitag 26 Juni 2009, Peter Berrington wrote:
> If anyone can take a look at my source and offer any advice I'd really
> appreciate it.

I've got the code to a point where it runs. I'm not sure that it does what it 
should, but since I don't know my way around GL, I didn't want to mess with it 
too much. You can find the results of my efforts at 
http://codepad.org/dRXTogs3. I've also checked that file into PyCUDA's 
repository as examples/gl_interop.py with a remark that it's unfinished, to 
make sure that the progress so far doesn't get lost.

Note that getting this far also required a fix in PyCUDA's GL interop bits--so 
do a git pull and rebuild before you start playing.

Thank you very much for your effort and perseverence at this!
Andreas


signature.asc
Description: This is a digitally signed message part.
___
PyCUDA mailing list
PyCUDA@tiker.net
http://tiker.net/mailman/listinfo/pycuda_tiker.net


Re: [PyCuda] OpenGL and polling

2009-02-21 Thread Andreas Klöckner
On Samstag 21 Februar 2009, Nicholas S-A wrote:
> The only problem is that I am printing status information, and
> prepared_async_call() doesn't actually return a zero-tuple as far as I
> can tell. Is this improved in 0.92? I am currently running 0.91 and
> don't want to go through more upgrade headache if it isn't going to add
> anything for me ;)

Whoops, that was a doc bug in prepared_async_call. It's supposed to return 
None. (And that is and has been the behavior of the code.) If you want the 
timing function that the docs used to promise--that's what 
prepared_timed_call() is for. :) That had a doc bug, too--it doesn't take a 
'stream' parameter. (If you need timing *and* streams, you can easily build 
that yourself from Events and prepared_async_call--look at the implementation 
to see how it's done.) I've fixed all the doc bugs.

Regarding fear of upgrades: Use a disposable virtualenv.

Andreas


signature.asc
Description: This is a digitally signed message part.
___
PyCuda mailing list
PyCuda@tiker.net
http://tiker.net/mailman/listinfo/pycuda_tiker.net


Re: [PyCuda] OpenGL and polling

2009-02-21 Thread Nicholas S-A

Hi,

* Andreas Kl?ckner  [2009-02-03 09:36:21 -0500]:

Try the SCHED_YIELD argument to Device.make_context(). Haven't tried  it, it's 
advertised as doing just that. You can then do the actual polling with either 
Stream.is_done() or Event.query().


Sorry I didn't get back to you about this earlier. I passed the
SCHED_YIELD argument, and it works great! My CPU is down almost zero :)
Thanks!

The only problem is that I am printing status information, and
prepared_async_call() doesn't actually return a zero-tuple as far as I
can tell. Is this improved in 0.92? I am currently running 0.91 and
don't want to go through more upgrade headache if it isn't going to add
anything for me ;)


Thanks so much!

nick

p.s. My code has quite a lot of rewriting and dynamic variable/parameter
generation, so I will post to the list once it is released (GPL) as an
example if anyone is interested...

___
PyCuda mailing list
PyCuda@tiker.net
http://tiker.net/mailman/listinfo/pycuda_tiker.net


Re: [PyCuda] opengl PBOs and pycuda

2009-02-12 Thread Andreas Klöckner
Hi Peter,

one request: please keep the list cc'd--maybe somebody there knows something.

On Donnerstag 12 Februar 2009, Peter Berrington wrote:
> Still no dice, there is always an error initializing or making the gl
> context regardless of whatever I make a standard cuda context before, or
> whether I use  pycuda.gl.init(), pycuda.gl.make_context(), or importing
> pycuda.gl.autoinit to try and set up a gl context, I always end up with
> these cryptic messages:
>
> pycuda._driver.Error: cuGLInit failed: unknown
>
> or
>
> pycuda._driver.Error: cuGLCtxCreate failed: unknown

Does dmesg say anything?

> Do you have the cuda 2.0 SDK handy by any chance? I'm trying to recreate
> the behaviour of the postProcessGL program which is included, but I noticed
> they do not explicitly set up an opengl context in that code; there is a
> single call to cutilDeviceInit(argc, argv) as the program is initialized
> but I don't know whether that ends up calling cuGLInit or not, as its part
> of the cuda cutil library. Any ideas what might be wrong?

cutil source is included under common/, there's no GL stuff in there. There's 
also no explicit GL interop initialization in the SDK--for the runtime API, 
that's apparently not necessary.

Check this here, too:
- http://forums.nvidia.com/index.php?showtopic=58779&hl=cuGLInit

If you're still not having any luck, I'll try to get some help from Nvidia.

Andreas


signature.asc
Description: This is a digitally signed message part.
___
PyCuda mailing list
PyCuda@tiker.net
http://tiker.net/mailman/listinfo/pycuda_tiker.net


Re: [PyCuda] opengl PBOs and pycuda

2009-02-11 Thread Andreas Klöckner
On Mittwoch 11 Februar 2009, Peter Berrington wrote:
> Thanks a lot for working on that Andreas. I'd be more than happy to write a
> tutorial/example and documentation, but I wasn't able to get it working
> when I played around with it earlier today. I assume that I should first
> call import pycuda.gl.autoinit to set up a context, however that throws
> this error:
> pycuda._driver.LogicError: cuGLInit failed: invalid context
>
> If I instead use the standard pycuda autoinit and then try to call
> pycuda.gl.init() directly it instead fails with
> pycuda._driver.Error: cuGLInit failed: unknown
>
> I browsed around in the source but I'm afraid I couldn't see anything that
> looked obviously wrong, although there was apparently a mispelling in the
> gl/autoinit.py file: The function pycuda.gl.make_gl_context(device) is
> called but it looks that module only has a make_context() function, not a
> make_gl_context function.

Fixed, thanks.

> Am I misunderstanding how to go about initializing pycuda? If not, is there
> any more information I can provide that might help you identify why
> cuGLInit function call fails? Thanks!

I've googled around a bit and written up my findings at

http://documen.tician.de/pycuda/gl.html

(Pull recent git to get the updated autoinit.)

Andreas


signature.asc
Description: This is a digitally signed message part.
___
PyCuda mailing list
PyCuda@tiker.net
http://tiker.net/mailman/listinfo/pycuda_tiker.net


Re: [PyCuda] opengl PBOs and pycuda

2009-02-10 Thread Andreas Klöckner
On Dienstag 10 Februar 2009, Peter Berrington wrote:
> I didn't see any response on the mailing list so I thought I'd ask again.
> Has anyone made any attempt at wrapping the cuda opengl interop functions
> in pycuda? I've never used boost before and I'm not sure how to proceed.
> I'd really like to be able to use pycuda to post process an opengl pixel
> buffer object but without the cudaGLRegisterBufferObject and
> cudaGLMapBufferObject functions I don't see how I can do this.

I predict that after reading this email, you'll be very happy.

Check recent git, configure with --cuda-enable-gl=1. (or CUDA_ENABLE_GL=True 
in siteconf.py, whichever style you prefer)

It compiles for me, but is otherwise entirely untested. I would like you to do 
three things in return:

- Test and report back with the result. (I have no way of doing so.)
- Write the simplest possible example that does something useful and submit it 
for inclusion.
- Fill out the documentation in doc/source/gl.rst and submit a patch.
Also see http://documen.tician.de/pycuda/gl.html.

> I saw there was a recent release of codepy; would codepy allow one include
> and call the C cuda opengl functions directly or am I misunderstanding how
> it works? 

codepy in principle would allow you to do that, but since PyCuda already 
builds a Boost.Python extension as part of its build, that would be a rather 
roundabout and non-portable (Linux-only) way of doing it.

> Thanks for your response.

You're welcome. :)

Andreas


signature.asc
Description: This is a digitally signed message part.
___
PyCuda mailing list
PyCuda@tiker.net
http://tiker.net/mailman/listinfo/pycuda_tiker.net


Re: [PyCuda] OpenGL and polling

2009-02-03 Thread Andreas Klöckner
On Freitag 30 Januar 2009, Nicholas S-A wrote:
> Hi all,
>  I have two questions about PyCUDA which I have run up against in my
> testing to use it for a few applications:
> 1) Is there any integration between PyOpenGL/PyGame and PyCUDA like
> there is between PyCUDA and OpenGL where VBOs can be shared on the
> device?

Way back in the archives, Evan Wies said something about GL interop--maybe you 
could get in touch with him and see if something became of that. I'd be happy 
to take a patch.

Andreas


signature.asc
Description: This is a digitally signed message part.
___
PyCuda mailing list
PyCuda@tiker.net
http://tiker.net/mailman/listinfo/pycuda_tiker.net


Re: [PyCuda] OpenGL and polling

2009-02-03 Thread Andreas Klöckner
On Freitag 30 Januar 2009, Nicholas S-A wrote:
> Hi all,
>  I have two questions about PyCUDA which I have run up against in my
> testing to use it for a few applications:
> 1) Is there any integration between PyOpenGL/PyGame and PyCUDA like
> there is between PyCUDA and OpenGL where VBOs can be shared on the
> device?
> 2) Can I poll the GPUs instead of blocking? Right now I have three
> python threads which are running three CPUs at 100% to... wait for the
> GPUs. Timing isn't too tight and I could easily get away with polling
> every second or two (to drop CPU usage), but I haven't figured out a way
> to do that yet.

Try the SCHED_YIELD argument to Device.make_context(). Haven't tried  it, it's 
advertised as doing just that. You can then do the actual polling with either 
Stream.is_done() or Event.query().

HTH,
Andreas


signature.asc
Description: This is a digitally signed message part.
___
PyCuda mailing list
PyCuda@tiker.net
http://tiker.net/mailman/listinfo/pycuda_tiker.net


Re: [PyCuda] OpenGL Interop

2008-10-31 Thread Andreas Klöckner
On Freitag 31 Oktober 2008, Evan Wies wrote:
> Sorry if this has been discussed before, but I can't seem to access
> the mailing list archives.

I know, I'm working on that with my hosting provider. I hope they haven't 
deleted them. I've requested gmane.comp.python.cuda to archive PyCuda's list, 
but that only has *very* recent history.

> Has anybody worked on OpenGL interoperability for PyCuda?  There are a
> small set of CUDA functions needed for this and performing binding is
> pretty straightforward.  I was playing around with various ways of
> doing, but am not yet familiar enough with the PyCuda object model to
> know the best design choices.

Hasn't been done or discussed, but should be quite easy, if you just follow 
the example of what's there. Tying to PyOpenGL should also be easy enough as 
it uses ctypes. It also doesn't look like there will be added dependencies--
Nvidia's display drivers install a GL header file.

If you run into trouble, I'll be happy to help.

Andreas


signature.asc
Description: This is a digitally signed message part.
___
PyCuda mailing list
PyCuda@tiker.net
http://tiker.net/mailman/listinfo/pycuda_tiker.net