cancel
Showing results for 
Search instead for 
Did you mean: 

OpenCL

Highlighted
Adept I
Adept I

Problem with large FFTs using clAmdFft

I am using the clAmdFftClient-1.6.244 with the –d and –o options to generate an out of place kernel with a default fft size of 1024, and a single file called clAmdFft.kernel.Stockham1.cl is output.  Both the forward and reverse FFTs produce what I expect, and the workgroup size controls the batch (# of FFTs processed per kernel invocation). On a large buffer I measure a throughput of 20000 MB/s (2500 MS/s) on a gpu and a throughput of 560 MB/s (70 MS/s) on 12 cpus. Except for the low performance on the cpus, everything seems to be OK with the 1024 point FFT.

For larger FFTs, starting with 16384, the kernel generator writes two files, clAmdFft.kernel.Stockham2.cl and clAmdFft.kernel.Stockham3.cl. Neither kernel gives the output I expect. I tried operating with one followed by the other in case it is supposed to be a two-stage calculation, but I still did not get a correct answer. Can anyone shed some light on this?

0 Kudos
Reply
12 Replies
Highlighted

Re: Problem with large FFTs using clAmdFft

Hi sadrian,

Thanks for reporting your experience using our library. I have certain concerns about the way you are using the library.

Could you provide the reason why you want to dump the kernels and use them directly instead of using our library API? Ability to dump the kernels is supported by the library for informational puposes only and using the kernels directly is not how the library is designed to operate. I hope you went through our reference manual to understand how we would like the users to use our library. If you have not read this, please go through the pdf manual that came with the package, particularly section 1.4.

In your application, you would want to make a series of library API calls as shown below and link in clAmdFft library and let the library compute the transform. The function 'clAmdFftEnqueueTransform' is the function that enqueues kernels for FFT computation.

clAmdFftSetup( ... )

clAmdFftCreateDefaultPlan( ... )

clAmdFftSetPlanPrecision ( ... )
clAmdFftSetResultLocation( ... )
clAmdFftSetLayout( ... )
clAmdFftSetPlanBatchSize( ... )
clAmdFftSetPlanInStride( ... )
clAmdFftSetPlanOutStride( ... )
clAmdFftSetPlanDistance( ... )
clAmdFftSetPlanScale( ... )
clAmdFftBakePlan( ... )

clAmdFftEnqueueTransform( ... )
clFinish( ... )

...

clAmdFftDestroyPlan( ... )

clAmdFftTeardown()

Please let us know if you have trouble understanding any of our API functions. We value feedback and would be happy to improve our documentation to give the best experience for users.

Highlighted
Adept I
Adept I

Re: Problem with large FFTs using clAmdFft

Bragadeesh,

Thank you for your response. I have two reasons that I wanted to dump the kernels and use them directly. The first is that my OpenCL experience has so far spanned only the use of PyOpenCL. I have built up an infrastructure that has served rather well for investigation and profiling. I have known that in the future, the development of production software would probably require a migration to C or C++, but that point has not yet come for me and OpenCL.

A second reason is more philosophical and political. Let me first say that I have long been an advocate of OpenCL, if only a recent practitioner, and I am particularly excited about the possibilities surrounding AMD's APUs (especially when I saw that Sandia laboratory is already building a supercomputer to use OpenCL on APUs). That being said, I work where CUDA is the GPU programming environment of choice despite my arguments that OpenCL development should be adopted.

From your response, I see that is was never AMD's intention to support use of pre-generated kernels, though I am guessing that there is no technical reason this has to be the case. The need to link to a proprietary library, however, weakens my case for OpenCL. I can already hear the responses: "If we have to link to a proprietary library anyway, we might as well link to CUDA libraries....."

I guess I will now move on to investigate and profile my Plan B choice, the Apple FFT OpenCL kernel.

Highlighted
Adept II
Adept II

Re: Problem with large FFTs using clAmdFft

>We value feedback

I think you guys should make it so that you don't have to use 13 API calls every time you want to do a batch of GPU work. 

I am working on some educational material demonstrating how to use AMD OpenCL with CL/GL interop, and I am using another toolkit for the OpenGL part of it.  The way the fft library is designed to be used makes it difficult (impossible?) to use a different interface to the GPU.  In other words, if the code in my animation loop for OpenGL has to be the same C/C++ program that the AmdFFT code is compiled with then that eliminates a lot of other frameworks out there that make GL development easier.

0 Kudos
Reply
Highlighted
Staff
Staff

Re: Problem with large FFTs using clAmdFft

Hi kbrafford~

You don't have to use 13 API calls every time you wish to process a batch of transforms.  The API clAmdFftCreateDefaultPlan() is named such because it provides what we think are reasonable defaults for all plan state.  Those defaults are documented, and should represent common values, except for state that is domain specific, like # of dimensions and vector lengths.  In addition, once the state is set, it is 'sticky' and you don't need to set it again for the next clAmdFftEnqueueTransform() call.  You can copy plans with clAmdFftCopyPlan() if you wish to create similar plans that are slightly different.  Finally, once clAmdFftBakePlan() is called, the OpenCL kernel is compiled into bytecode, so the developer can control when the kernel compile happens.  The API was designed to support this usage model in a flexible and efficient manner.

As a reminder, unlike BLAS, there is no standard for FFT interfaces.  FFTW does exist as an interface that enjoys a lot of developer mindshare, and it employs the same concept of 'plans' that clAmdFft uses.  I personally don't feel that the clAmdFft interface is more complex than any other commonly used FFT interface, including FFTW.

Please let me know if I am not answering your concerns correctly.

0 Kudos
Reply
Highlighted
Adept II
Adept II

Re: Problem with large FFTs using clAmdFft

Ah, I gotcha.  I understand how the interface is designed to give you a rich set of options and clearly indicate how features will be added as they are ready.  But  I didn't mean to emphasize the number of API calls as my main stumbling block. 

Is it possible to use the Amd CL FFT library with an application that isn't a C/C++ executable compiled and linked with the library at compile time?  I would like to be able to use the AMD FFT library to make a kernel that I can use with the Python OpenCL interface that I am using. 

Like the original poster sadrian, I am using PyOpenCL to perform some calculations, and I am trying to use the Pyglet interface to OpenGL,which can work nicely with OpenCL. See for instance:

http://enja.org/2011/03/22/adventures-in-pyopencl-part-2-particles-with-pyopengl/index.html

0 Kudos
Reply
Highlighted
Staff
Staff

Re: Problem with large FFTs using clAmdFft

We unfortunately do not have a python interface to our libraries yet.  Since our libraries do export a clean “C” interface, I do believe that it’s possible to create python wrappers to our libraries, but we haven’t had the resources to investigate how to properly do this.

0 Kudos
Reply
Highlighted
Adept II
Adept II

Re: Problem with large FFTs using clAmdFft

I'm working on making a Python wrapper module for the AMD FFT library, using the same interface generator that PyOpenCL uses (Boost.Python C++ library).

0 Kudos
Reply
Highlighted
Staff
Staff

Re: Problem with large FFTs using clAmdFft

That's great!  Please keep us posted on your experience creating the wrapper.

0 Kudos
Reply
Highlighted
Adept II
Adept II

Re: Problem with large FFTs using clAmdFft

FYI,

I started a discussion about it on the PyOpenCL forum, and found another guy interested in helping out:

http://news.gmane.org/find-root.php?group=gmane.comp.python.opencl&article=1199

--Keith Brafford

0 Kudos
Reply