GPUPI - SuperPI on the GPU - Post results!

https://www.overclockers.at/attachme...8154&thumb=450

In the last weeks I've implemented GPUPI, a benchmark that computes pi in parallel via OpenCL. It was something that I wanted to do for years, but never got that far. Somehow I successfully implemented it and it's currently in beta version. Have a look at it, it's pretty fun to crunch pi on your gpu. :toast:

https://www.overclockers.at/attachme...8372&thumb=350 https://www.overclockers.at/attachme...8373&thumb=350 https://www.overclockers.at/attachme...8374&thumb=350
GPUPI 1B: AMD Radeon R9 290, NVIDIA GeForce GTX 980 and Intel Core i7-4960X@4 GHz

I am aware that FUGGER and his team wanted to do something like that for some time. I don't want to piss anybody off, on the contrary! I just think that SuperPI on the GPU has something magical and the idea never got out off my head.

I'd also like to dedicate this benchmark to our beloved Turrican. He will always be missed. :(

Download, technical details & FAQ: GPUPI Beta 1.2

______________________________________________

Please post any results you got in this thread! I would love to see some heavy Quadros and FirePro cards, altough double precision performance should not be too much of an advantage. If there's a bug, other issues and feedback, just let me know. I will monitor this thread closely.

Important: Please use the latest graphics/OpenCL drivers, there's available. Old drivers seem to be pretty buggy with double precision.

Τhis is my result with stock GPU clocks :

http://i256.photobucket.com/albums/h...psc42cc352.png

Here's mine. ASUS R9 290x ROG something.

http://i.imgur.com/2AM2Vyt.jpg

Not a problem at all, I will poke at Nvidia again to see if we can complete the CUDA version.

With time we will see a good sample of AMD GPU's performance in a new way.

This will run on APU too?

I already have a CUDA version, I implemented it before porting to OpenCL. CUDA has the nicer toolkit and much easier to develop an idea. But the goal was to let NVIDIA and AMD compete in the same bench.

Yes, AMD has a very nice Integer performance and that helps a lot in this bench. So whatever is good a mining bitcoins should also have a nice performance in GPUPI. But it's not that easy: The benchmark uses multiple precisions for various parts of the calculation. I guess it's about 75% 64 bit integer performance and 25% double precision. Just a rough guess, I could measure it sometime if it's important for understanding and optimizing the benchmark.

Yes, it runs on APUs and even on CPUs.

Hmmm., maybe I can try APU quickly this week :).

can i run this in crossfire lol

Currently SLI and Crossfire are not possible, please have a look at the FAQ. But it's definitely possible in the future, I just need multiple cards to develop and implement it. Let's see if the vendors can help us out. :)

So, my GPU at stock, R9-270X ToXIC and FX-9590 4715 MHz (hmmm, its not bad in SUperpi with all threads...)

https://farm8.staticflickr.com/7463/...4db8892a_z.jpg

https://farm6.staticflickr.com/5608/...388630c0_z.jpg

http://i503.photobucket.com/albums/e...ps654c75ef.png

Thanks for this _mat_, but, why is this faster on CPU's than SuperPI? It's easy to get below 2s for 1M.
Was the old code obsolete after all?
Is it quicker because of OpenCL and the use of modern CPU instructions?

First of all it's a completely different algorithm to calculate pi. It uses the BPP formula, the only pi formula that can be computed in parallel. That said it only crunches 9 digits from 1M, exactly the 1.000.001th to the 1.000.010th. SuperPi calculates every digit to 1M, as most of the serial formulas do. The reason is that the calculation always depends on the result in the step before. That is why they can't make use of more than one core, let alone hundreds of cores on a graphics card.

My benchmark is not very much optimized for CPUs, call it a side effect that it even runs properly on them. It uses FMA every know and then and a double2 data type (for doubledouble arithmetic), but that's pretty much it. Altough the OpenCL driver that compiles the kernels on the fly, can do some autovectorization to improve the performance. Even though I have not intentionally optimized the kernel code, as I have done it for AMD and NVIDIA cards.

Quote:

---

Originally Posted by TimPrice

Thanks for this _mat_, but, why is this faster on CPU's than SuperPI? It's easy to get below 2s for 1M.
Was the old code obsolete after all?
Is it quicker because of OpenCL and the use of modern CPU instructions?

---

SuperPi compute all (decimal) digits from start to N. The algorithm used in SuperPi is (for simplicity) not parallelizable. That's why the initial SuperPi on GPU project didn't get anywhere.

As mentioned by __mat__, his program does something completely different. It computes a few (hexadecimal?) digits starting at the N'th place. This task, uses the BBP formula which is very parallelizable.

Unfortunately, all known efficient algorithms to compute all digits from start to N are difficult to parallelize. Not to hijack this thread, but my y-cruncher program attempts to do this. But it doesn't do it well enough for GPU (not to mention memory bottlenecks).


Nice work __mat__! This is the first BBP-based Pi benchmark for GPUs that I've ever seen.

its clear this is quicker than superpi. Old superpi is without instrucitons and only for one core (x87 only and not much effective at one core)...

Quote:

---

Originally Posted by poke349

Nice work __mat__! This is the first BBP-based Pi benchmark for GPUs that I've ever seen.

---

Hey poke, I've been watching your y-cruncher project for some time now. I even used it to externally validate my hexadecimal results for 32B. Your kind words are very much appreciated!

first run

http://imagizer.imageshack.us/v2/160...537/DCHQzF.png

Is this software using double precision?
Changing the DPFP from 1/8 to 1/2 on Hawaii makes barely any difference at all?

Also compiling the kernel appears to give several errors in CodeXL for example.

Quote:

---

Originally Posted by The Stilt

Is this software using double precision?
Changing the DPFP from 1/8 to 1/2 on Hawaii makes barely any difference at all?

Also compiling the kernel appears to give several errors in CodeXL for example.

---

It uses doubledouble arithmetic by splitting the precision into two doubles. But that's only for a final division with high precision. Double precision performance is more important for calculations smaller than 1B. 1B and above has to make use of special uint128 arithmetic to calculate modpow by using Montgomery exponantiation. So 1B is pretty much bound to the 64 bit integer performance of the device.

I will have a look at CodeXL, but I don't care too much about the AMD APP SDK, it's a mess. The kernels are compiled in realtime on the target device anyways.

http://imagizer.imageshack.us/v2/xq90/661/smjZT0.png

Here's mine from the living-room pc.

http://i1142.photobucket.com/albums/...ps8e8ae6c1.png

EVGA GTX 980 ACX SC @ 1580 / 8ghz

http://i.imgur.com/vHmD2fC.png