Lucas–Lehmer on on ATI's GPUs (OpenCl or Stream)
 

Hi,
I open this 3d because, in this forum, I found a good work on cuda, but none develop for ATI.

This thread want to form a group interested to program based on lucas-lehmer test (that can interact with PrimeNet) for gpu ATI in brook+ (ATI stream) language or better in Opencl (so it can run also on nvidia)

I think that gpgpu can increase result of gimps

sanzo

Are you sure the current release of openCL will generate efficient enough code for any GPU? IIRC as of a few months ago the AMD OpenCL implementation had severe performance problems because it could not use the high-speed local memory on ATI GPUs.

yes,[COLOR=#000000]you're right,[/COLOR] infact is better to use ATI stream (Brook+ lang)....

Thanks

sanzo

PS: I citate OpenCl because it is the only one open and supported by AMD and Nvidia.

Jason, do you know if the OpenCL community is of the type that does a decently-rapid turnaround on major issues like the one you mention?

I am keen to start doing some GPU-dev this Fall, but my free coding time is very limited, and I absolutely want to avoid doing custom-dev work for every !%^%#@@& family of GPUs that comes around. (I think back to the 2 full years of evenings and weekends it took me to get all the the compute-core code in Mlucas SSE2-ified.)

[QUOTE=sanzo;227650]
I open this 3d because, in this forum, I found a good work on cuda, but none develop for ATI.
[/QUOTE]
The CUDA LL code is based on nVidia's FFT library. As far as I am aware, ATI has not released an FFT library for their cards. Once that happens, porting to ATI could begin.

How difficult would it be to write our own FFT library?

[QUOTE=ewmayer;227692]Jason, do you know if the OpenCL community is of the type that does a decently-rapid turnaround on major issues like the one you mention?
[/QUOTE]
I don't know. Nvidia has a pretty substantial first-mover advantage in this field, CUDA has been out for almost 3 years now and has a pretty thriving developer community. Even then it was only in the last 6 months that we saw the LL test ported to use CUDA. OpenCL was released as a public standard late last year.

My own GPU code only needs integer arithmetic so it doesn't require a double-precision-capable GPU. If DP was a requirement I'd be stuck needing a more expensive board from each company, not to mention a much more powerful chassis to plug into.

As for how hard building a high-performance FFT would be, that's a subject many readers here have extensive experience answering. Getting something working is fairly easy. Tuning for maximum performance is always 10x more effort than you think it will be.

[QUOTE=jasonp;227727]My own GPU code only needs integer arithmetic so it doesn't require a double-precision-capable GPU. If DP was a requirement I'd be stuck needing a more expensive board from each company, not to mention a much more powerful chassis to plug into.[/QUOTE]
I'm operating under the assumption that recent trends will continue, i.e. that DP support will continue to increase among the available GPU offerings and power consumption per FLOP will keep decreasing.

In other words, that the trend in the GPU field will mirror that in the CPU world: as time goes on, an ever-increasing fraction of the compute hardware gets devoted to floating-point work. The x86 evolution: MMX -> SSE -> SEE2/3/4... -> AVX illustrates this nicely.

I'm also going to speculate that a lot of the ever-increased-parallelism described in the current SSE-to-AVX-and-beyond roadmap may well end up getting implemented in a future series of Intel and AMD CPUs.

[quote=frmky;227716]The CUDA LL code is based on nVidia's FFT library. As far as I am aware, ATI has not released an FFT library for their cards. Once that happens, porting to ATI could begin.[/quote]

Sorry, but OpenCl has a "Fast Fourier Transform" library too.

The latest driver release (10.10) has something called "AMD Catalyst™ Accelerated Parallel Processing (APP) Technology Edition". The only difference to the default package is OpenCL Driver. Something usefull? ;)

Just a sassy name. 5970 issue still not fixed for OpenCL.