In sample itself only main.cpp mostly changed, device initialization was replaced by same thing from TemplateC sample.
fft_setup.cpp unchanged,
in other file where required all log2() calls were replaced with int_log2() call, where:
inline int int_log2(int input) {
int i = 0;
while(input >>= 1) i++;
return i;
}
I already incorporated needed fft call into my app where fftw was used before.
Relevant places are:
fft plan init:
#if USE_FFTW
wisdom.load();
fp = fftwf_plan_dft_1d(2048/*fft_len*/, data, data, FFTW_FORWARD, FFTW_MEASURE);
#endif
#if USE_OPENCL //R
penCL related FFT
clFFT_Dim3 n;
n.x=2048;//fft_len;
n.y=n.z=1;
cl_int err=CL_SUCCESS;
plan = clFFT_CreatePlan( context, n, clFFT_1D, clFFT_InterleavedComplexFormat, &err );
if(!plan || err)
{
fprintf(stderr,"ERROR: clFFT_CreatePlan failed\n");
exit(0);
}
#endif
fft call:
#elif USE_OPENCL
cl_int err = CL_SUCCESS;
data_in = clCreateBuffer(context, CL_MEM_READ_WRITE | CL_MEM_COPY_HOST_PTR, 2048/*fft_len*/*sizeof(float)*2, data, &err);
if(!data_in)
{
fprintf(stderr,"ERROR: clCreateBuffer failed\n");
goto cleanup;
}
data_out = data_in;//R:inplace transform for now
err |= clFFT_ExecuteInterleaved(commandQueue, plan, 1, clFFT_Forward, data_in, data_out, 0, NULL, NULL);
err |= clFinish(commandQueue);
if(err)
{
fprintf(stderr,"ERROR: clFFT_Execute\n");
goto cleanup;
}
err |= clEnqueueReadBuffer(commandQueue, data_out, CL_TRUE, 0, 2048/*fft_len*/*sizeof(float)*2, data, 0, NULL, NULL);
if(err)
{
fprintf(stderr,"ERROR: clEnqueueReadBuffer failed\n");
goto cleanup;
}
cleanup:
if(data_in)
clReleaseMemObject(data_in);
#elif USE_FFTW
fftwf_execute(fp);
fft_setup.cpp unchanged,
in other file where required all log2() calls were replaced with int_log2() call, where:
inline int int_log2(int input) {
int i = 0;
while(input >>= 1) i++;
return i;
}
I already incorporated needed fft call into my app where fftw was used before.
Relevant places are:
fft plan init:
#if USE_FFTW
wisdom.load();
fp = fftwf_plan_dft_1d(2048/*fft_len*/, data, data, FFTW_FORWARD, FFTW_MEASURE);
#endif
#if USE_OPENCL //R
penCL related FFT clFFT_Dim3 n;
n.x=2048;//fft_len;
n.y=n.z=1;
cl_int err=CL_SUCCESS;
plan = clFFT_CreatePlan( context, n, clFFT_1D, clFFT_InterleavedComplexFormat, &err );
if(!plan || err)
{
fprintf(stderr,"ERROR: clFFT_CreatePlan failed\n");
exit(0);
}
#endif
fft call:
#elif USE_OPENCL
cl_int err = CL_SUCCESS;
data_in = clCreateBuffer(context, CL_MEM_READ_WRITE | CL_MEM_COPY_HOST_PTR, 2048/*fft_len*/*sizeof(float)*2, data, &err);
if(!data_in)
{
fprintf(stderr,"ERROR: clCreateBuffer failed\n");
goto cleanup;
}
data_out = data_in;//R:inplace transform for now
err |= clFFT_ExecuteInterleaved(commandQueue, plan, 1, clFFT_Forward, data_in, data_out, 0, NULL, NULL);
err |= clFinish(commandQueue);
if(err)
{
fprintf(stderr,"ERROR: clFFT_Execute\n");
goto cleanup;
}
err |= clEnqueueReadBuffer(commandQueue, data_out, CL_TRUE, 0, 2048/*fft_len*/*sizeof(float)*2, data, 0, NULL, NULL);
if(err)
{
fprintf(stderr,"ERROR: clEnqueueReadBuffer failed\n");
goto cleanup;
}
cleanup:
if(data_in)
clReleaseMemObject(data_in);
#elif USE_FFTW
fftwf_execute(fp);
More info about issue:
I just completed size 2048 FFT using oclFFT on Q9450 CPU device instead of HD4870 ATI GPU device.
Results very similar with FFTW ones !
That is, nothing wrong IMO with code per se, something wrong when it executed on ATI's GPU specifically!
ATI OpenCL crew, your turn
I just completed size 2048 FFT using oclFFT on Q9450 CPU device instead of HD4870 ATI GPU device.
Results very similar with FFTW ones !
That is, nothing wrong IMO with code per se, something wrong when it executed on ATI's GPU specifically!
ATI OpenCL crew, your turn
Originally posted by: MicahVillmow
Raistmer,
This is a known issue that we are working on a fix for.
Ah, thanks for info. Please, keep me informed on progress, you know how badly I need FFT for ATI GPUs
There are many owners of 5xxx cards already who will to run my app, but w/o promised update to SDK they can't produce valid results with their GPUs.
Few months passed already, now we approach to "many months" area
When we can expect new SDK release? Or maybe I can get at least some kind of hotfix for described issue ??
Few months passed already, now we approach to "many months" area
When we can expect new SDK release? Or maybe I can get at least some kind of hotfix for described issue ??
Originally posted by: fulcrum_xyz
Thanks Raistmer, I have the apple version...and currently porting it to run on my OpenSUSE 11.2.
So, I was wondering if you had already ported it to a linux (non MacOS version) and if you could share that ?
thanks again...
P.S: I have taken a look at the OpenCL SDK FFT sample, that seems to be very preliminary and support very minimal parameters (on 1D, no batching, no complex)...
SDK sample just not worth mention actually. It's hardwired to single FFT size, just some technique demonstation, not useful piece of code for FFT.
Usable FFT was promised in next SDK release, will see
About linux porting there was attempt with earlier bugged SDK (2.0) and as far as I can remember it works even better than windows part. So there should be no problems on linux with current SDK.
With SDK 2.0 default base radix of 128 failed. value of 32 was used. But currently I see better performance on 1D 32k-size transform for old 128 value (and it works).
Smaller base radix of 32 better suited for app that uses 1D FFT with different sizes from 8 to 128k.
There are few parameters for playing. I use HD4870 GPU, obsolete hardware from AMD point of view
, so someone with newer HD5xxx card could see different performance optimum. 
