4 Replies Latest reply on Jan 15, 2013 11:32 AM by dafydd2

    Downloading older versions of clAmdFft

    dafydd2

      I have a computer with a HD 4850, which has been moved into the legacy bracket of AMD products and is only compatible with OpenCL 1.1. Which version of clAmdFft is the most recent that will run properly on it, and where can I download it? The only Windows version available for download is 1.8.239.

       

      Also, the readme lists several fixes in later versions (e.g. Version 1.8.276 (beta): Fixed:  * Memory leaks affecting use cases where 'clAmdFftEnqueueTransform' is used in a loop) than the one available for download. Are those bugs not actually fixed in the version available for download, or is the version available for download not actually 1.8.239?

       

      By the way, according to the website, the readme is an rtf, but it's really a .txt.

        • Re: Downloading older versions of clAmdFft
          bragadeesh

          In general, we support graphics cards up to 2 generations old. The 4850 that you have is more than 2 generations old and we are unable to provide support.

           

          Please note that the minor version number is different between Windows and Linux. You may have the version numbers mixed up. We don't have the older versions of the library available for download.

          1 of 1 people found this helpful
            • Re: Downloading older versions of clAmdFft
              dafydd2

              About the 4850: ok.

               

              About the versions: what do you mean I have the version numbers mixed up? The readme clearly states

               

              "Version 1.8.276 (beta):

              Fixed:

                * Memory leaks affecting use cases where 'clAmdFftEnqueueTransform' is used in a loop"

               

              and the version available for Windows is 1.8.239. Am I to assume, henceforth, that if a fix is listed in the readme, the version available for download is fixed, regardless of the version number? The readme does in no way clarify that the version numbers indicated refer to the Linux version numbers and not the Windows version numbers, hence the confusion. For the record, I'm having crash issues when using clAmdFftEnqueueTransform in a loop (the temporary buffer must be allocated manually if clAmdFftEnqueueTransform is called more than once in a program or the graphics driver crashes - this is not mentioned in the manual), so I was thinking the issue had yet to be fixed for Windows.

                • Re: Downloading older versions of clAmdFft
                  bragadeesh

                  Thanks. Now I understand where the confusion is arising from. The readme file available directly for download is for the Linux version. You are right that it does not say explicitly it is for Linux. We will make changes to clarify this.

                   

                  In general, we would like the user to read the readme file that is part of the install package. The files in them say version numbers specific to the OS where the library gets installed. Please read the Windows specific readme file (part of the 1.8.239 package) and let us know if it clarifies things. Also, do let us know if you are still seeing failures.

                  1 of 1 people found this helpful
                    • Re: Downloading older versions of clAmdFft
                      dafydd2

                      Yes, the Windows readme appears to have the same contents as the readme on the webpage. However, the date in the Windows readme states it's from August 22, 2012, while the Linux readme on the webpage says September 2012, and the date on the webpage next to the download link state the release date as September 19 2012 for both the Windows and the Linux version.

                       

                      On a different topic, I'm also seeing greatly reduced precision for transforms of 3600 elements (the last 600 elements, specifically) on both a HD 6320 and a HD 7870, orders of magnitude worse than any other size in the interval (2^8-2^22). I will return shortly with more details, but I'm pretty sure this is a bug. I'm also having problems with RAM getting filled up when running many different plans (I'm trying to run one transform of every size in the aforementioned interval during one execution of the same program as part of benchmarking ClAmdFft). Destroying the plans doesn't seem to help, but tearing down ClAmdFft and setting it up again does, however after doing this a few times (5 or so) the program crashes for reasons I have yet to identify. If it turns out to be because of ClAmdFft and not some bug of my own, I'll return with more information, but if any of this happens to be known issues in ClAmdFft, please let me know!