Hello.
Few quick updates regarding status of PyOpenCL and PyCUDA in Debian.
PyCUDA is in testing (future Stretch), rebuild agains CUDA 8.0. Not
many changes there.
PyOpenCL is in unstable. I uploaded version built against few
additional architectures (not only amd64 and i386) - so please test if
you have appropriate hardware. My goal is to have PyOpenCL built for
all architectures for whose there is ICD provider in Debian. It looks
like there is some problem with some of the architectures and that’s
why package has not yet migrated to testing. Basically different ICDs
are for different architectures so I need to maintain list of them
manually. Again - please test.
At the same time I have a question for you Andreas. There will be
freeze of Stretch on 2017-01-05. I’d like to upload PyOpenCL and PyCUDA
in mid-December, and those versions will be versions for Stretch. Do
you plan new releases, or should I just take snapshots from git?
Best regards.
--
Tomasz Rybak, Debian Maintainer <tomasz.rybak(a)post.pl>
GPG: A481 824E 7DD3 9C0E C40A 488E C654 FB33 2AD5 9860
http://member.acm.org/~tomaszrybak
Hi all,
I created an |pyopencl.Image| object via:
|importpyopencl ascl importnumpy asnp ctx =cl.create_some_context()image
=cl.image_from_array(ctx,np.ones((16,16),dtype=np.uint8))|
How can I obtain the image channel type information (here,
|cl.channel_type.UNSIGNED_INT8|)? I want to implement a generic
downloading function that returns a numpy array given an |Image|.
I tried two approaches:
Using |Image.element_size| gives me the byte size of a single element,
however I can't map the element size to a data type (float32 and int32
have the same element size, for instance).
|Image.format| returns a |cdata 'struct _cl_image_format &'|. Querying
either of the fields |image_channel_data_type| and |image_channel_order|
returns 0, the default values of the ImageFormat constructor.
Or do you recommend a different approach (using Array, f.i.)?
Thanks in advance
Philipp
