13 Replies Latest reply on Jan 21, 2013 8:27 PM by dkissick

    Problems building clAmdFft library

    kbrafford
      How do people use this thing?

      I am having a hard time using the library.  I am using VS 2008 and have boost 1.44 isntalled.  The configuration and generation seemed to work, but when I try to build my solution I get this:

       

       

      1>------ Rebuild All started: Project: ZERO_CHECK, Configuration: Debug Win32 ------ 1>Deleting intermediate and output files for project 'ZERO_CHECK', configuration 'Debug|Win32' 1>Checking Build System 1>CMake does not need to re-run because C:/AMD/clAmdFft-1.0.53/Build/CMakeFiles/generate.stamp is up-to-date. 1>Build log was saved at "file://c:\AMD\clAmdFft-1.0.53\Build\ZERO_CHECK.dir\Debug\BuildLog.htm" 1>ZERO_CHECK - 0 error(s), 0 warning(s) 2>------ Rebuild All started: Project: clAmdFft.Client, Configuration: Debug Win32 ------ 2>Deleting intermediate and output files for project 'clAmdFft.Client', configuration 'Debug|Win32' 2>Building Custom Rule C:/AMD/clAmdFft-1.0.53/samples/CMakeLists.txt 2>CMake does not need to re-run because C:\AMD\clAmdFft-1.0.53\Build\CMakeFiles\generate.stamp is up-to-date. 2>Compiling... 2>stdafx.cpp 2>clAmdFft.statisticalTimer.cpp 2>..\samples\clAmdFft.statisticalTimer.cpp(21) : error C2143: syntax error : missing ',' before '<' 2> ..\samples\clAmdFft.statisticalTimer.cpp(27) : see reference to class template instantiation 'Accumulator<T>' being compiled 2>..\samples\clAmdFft.statisticalTimer.cpp(21) : error C2039: 'unary_function' : is not a member of 'std' 2> ..\samples\clAmdFft.statisticalTimer.cpp(193) : see reference to class template instantiation 'Accumulator<T>' being compiled 2> with 2> [ 2> T=cl_ulong 2> ] 2>..\samples\clAmdFft.statisticalTimer.cpp(21) : error C2504: 'unary_function' : base class undefined 2>..\samples\clAmdFft.statisticalTimer.cpp(21) : error C2143: syntax error : missing ',' before '<' 2>..\samples\clAmdFft.statisticalTimer.cpp(25) : fatal error C1903: unable to recover from previous error(s); stopping compilation 2>clAmdFft.openCL.cpp 2>clAmdFft.client.cpp 2>Generating Code... 2>Build log was saved at "file://c:\AMD\clAmdFft-1.0.53\Build\clAmdFft.Client.dir\Debug\BuildLog.htm" 2>clAmdFft.Client - 5 error(s), 0 warning(s) 3>------ Skipped Rebuild All: Project: ALL_BUILD, Configuration: Debug Win32 ------ 3>Project not selected to build for this solution configuration ========== Rebuild All: 1 succeeded, 1 failed, 1 skipped ==========

        • Problems building clAmdFft library
          kbrafford

          Ok, I got it to build be adding this line in clAmdFft.statisticalTimer.cpp:

           

          How did other people get it to work?

          #include <functional>

            • Problems building clAmdFft library
              FrodoTheGiant

               

              Originally posted by: kbrafford Ok, I got it to build be adding this line in clAmdFft.statisticalTimer.cpp:

               

                How did other people get it to work?



              By doing what you did

               

              I already reported this to AMD about three weeks ago:

              http://forums.amd.com/devforum/messageview.cfm?catid=390&threadid=144152&enterthread=y

               

              Did you already compare AMDs FFT code with other implemenations? I found it to be much slower, compared to Apples FFT implementation.

              I would be interested in your benchmarks.

               

              cheers,

              F.

               

                • Problems building clAmdFft library
                  kbrafford

                  I haven't been able to do a comparison yet, as my application uses real FFTs and the library doesn't support those yet.  Also what I really want to do is use the library to make a proper .cl kernel file, then use that in my own application (like I saw you on another thread asking about).  Do you know if they are going to publish a guide for how to use those dumped kernel files?

                    • Problems building clAmdFft library
                      FrodoTheGiant

                       

                      Originally posted by: kbraffordDo you know if they are going to publish a guide for how to use those dumped kernel files?

                       

                       

                      I strongly doubt that!

                      But maybe someone from AMD can definitely answer this question?

                        • Problems building clAmdFft library
                          kbrafford

                          Oh man that's too bad.  The library is a neat concept, but I want to do two things with my AMD Opencl card that won't work with their library as it's set up now:

                          1) I want to use PyOpenCL.  If you haven't seen this project already, you really should look into it.  It makes it really really simple to get a project going.

                          2) I want to do opencl stuff on the GPU before the FFT as well as after the FFT.  I know the handle you get back from the FFT call lets you do post processing, but what about pre processing?

                          If they merely documented the interface to the baked kernels, the library would be way more useful to me.

                            • Problems building clAmdFft library
                              FrodoTheGiant

                               

                              Originally posted by: kbrafford

                              2) I want to do opencl stuff on the GPU before the FFT as well as after the FFT.  I know the handle you get back from the FFT call lets you do post processing, but what about pre processing?



                               

                              Where's the problem? clAmdFftEnqueueTransform() takes an OpenCL buffer as an argument. You fill this buffer with whatever you want BEFORE you call clAmdFftEnqueueTransform(), and you can do whatever you want with this buffer after the call. So pre/postprocessing is no problem.

                              E.g.

                              cl_mem data;

                              ... fill data ... do some preprocessing with it ... etc.

                              clAmdFftEnqueueTransform( plHandle_forward, CLFFT_FORWARD, 1, &cq, 0, NULL, NULL, &data, NULL, NULL);

                              ... use data with another kernel ... whatever ...

                              • Problems building clAmdFft library
                                kknox

                                 

                                Originally posted by: kbrafford Oh man that's too bad.  The library is a neat concept, but I want to do two things with my AMD Opencl card that won't work with their library as it's set up now:

                                 

                                1) I want to use PyOpenCL.  If you haven't seen this project already, you really should look into it.  It makes it really really simple to get a project going.

                                 

                                2) I want to do opencl stuff on the GPU before the FFT as well as after the FFT.  I know the handle you get back from the FFT call lets you do post processing, but what about pre processing?

                                 

                                If they merely documented the interface to the baked kernels, the library would be way more useful to me.

                                 

                                I will check into PyOpenCL in my spare time, at least to learn what it is; thank you for the suggestion.

                                Frodo is completely correct with regards to pre- and post- processing.  We specifically do NOT flush the command queue's when the user enqueues FFT kernels.  It is up to the user to decide when to flush work to the GPU's; pre and post processing kernels can be queued in the same command queue and flushed at once.

                                We are not going to document the interface to our kernels; at least for the short term.  We have too much work left to do, and as soon as we document the interface, we should provide backwards compatibility and support, and we are not ready for that.  Our kernel interfaces will change as we rev this library, but we realize it's nice to be able to read the kernels that we generate.

                                Thank you for your comments

                                  • Problems building clAmdFft library
                                    kbrafford

                                    Thanks for the information!

                                    BTW if you want any help getting started with PyOpenCL just let me know.  Even as a total newbie to OpenCL I successfully used PyOpenCL to write my first useful OpenCL solution (that happens to run fantastically on the 4850 as well as the 5870--not sure why that matters, but it makes me think I've hit upon a magic algorithm :-)  It is ridiculously simple to iterate over kernel changes, and when you couple in numpy and matplotlib (two very popular python modules) you can even quickly build demonstrations and unit/regression testing.

                                    • Problems building clAmdFft library
                                      kbrafford

                                      Any word on getting mag and phase instead of real and imag in the library?  Most of the stuff I do wants to know the former pair instead of the latter pair.

                                      Also, a nicely unwrapped phase would be super-awesome while you're at it :-)

                                  • Problems building clAmdFft library
                                    kbrafford

                                    Another thing...I don't have the docs with me, so I can't RTFM, but is there an option to get your FFT results as magnitude and phase instead of real and imaginary?  If not, that's a perfect example of something I'd like to tweak myself, if I were allowed to just use the kernels myself.