_mat_

No benchmark is really safe from cheating currently. You are welcome to add your constructive thought here to this discussion. You're right with the rest ... keep it to yourself.

The fastest one counts. Try to find a loop hole, then we can talk about discontinuance of points.

Nobody knew how fast 4x 290X would be on LN2. I had a a guess, but below 4 seconds is surpising nonetheless. In a good way though, the faster the better! I implemented the benchmark like SuperPi so getting faster with each generation is part of the game. Yes, that introduces some problems but it's better than having some batches/second counter. Don't you think? The only thing that comes to my mind is to reverse the problem. We could make the main category 20 or whatever seconds and the end result the number of digits the system was able to crunch in that time. Where I do see a problem is to validate those digits and how to handle them inside the HWBOT system.

Massman and I have discussed this topic for some time and it was a difficult decision. But I would dare to say, that we came to an understable conclusion. Please hear me out. This benchmark is very different to others that currently receive points. It scales very well with frequency and the number of graphics cards (up to 8 GPUs as theoretical limit). Additionally it likes some cards more than others. So a 290X is more than twice as fast than a GTX 980 ... and those are top modells for gamers and overclockers right now. That enables a huge performance spectrum ranging from an entry card like the HD 7770 or GTX 650 Ti at more than 2 minutes to the current world record of about 4 seconds. Yes, that's too short so let's look at other options: The next official choice would be 32B. The current single card record is 17 minutes, the world record is at about 6. All slower graphics cards will have to crunch for hours to get a result. Clearly the time for 32B as the main category that receives points has not come yet. It would also be possible to introduce a new bench target like 2B or maybe the existing 10B. I didn't propose them, because they are not that magical. 1B and 32B are the analogy to 1M and 32M of our beloved SuperPI and that's why I thought of them as the main categories. But whatever, let's take 10B for example. A GTX 980 with 1200 MHz needs 30 seconds for 1B and about 13 minutes to calculate 10B. Wait a minute ... why 13 and not only 5 minutes (10 times 30 seconds)? That's the problem here. For 1B the benchmark calculates the partial results up to 500 million with a way more efficient kernel. Higher numbers have to use arithmetic with more precision and that will slow down the calculation a lot. So 10B is actually more than 25 times slower than 1B. Too slow to be fun, no doubt. Just for the fun of it I added 2B to the next version of the benchmark. A GTX 980 with 1200 MHz needs about 2 minutes to calculate the result and it may push 4x 290X back to ~20 seconds or so: 2B might be a good alternative and we should dig into that. It would help the world record time indeed, but would it be more fun for most of us? No, because most of us will bench single card, maybe dual. And that's where 1B is currently the most fun and will be for some time in the future. So fark PR and their theatrics. I wrote this benchmark so overclockers have fun with it and that's all that matters to me. And without any doubts that's also what mattered most to our Turrican.

I've just tested a freshly compiled 64 bit version of GPUPI 2.1 and it's as fast as GPUPI 1.2 Beta. I will include it in the release!

I'll send out the latest version again today and include you. Sry, it didn't happen on purpose. Btw, it shouldn't be necessary to delete the 1.2 Beta submissions. I am currently testing GPUPI 2.1 in 64 bit and I hope it will be faster anyway.

New version is as good as done! I have added a few features to help the moderators: Automatic window resizing after a benchmark to avoid cutting of statistics or result. It's only done if necessary and helps especially for larger multi GPU systems. Ctrl+A selects all text in output window now Watermark for invalid results: HWBOT crew is still testing the new timing methods. Haven't heard much from them, but I hope we will release soon. Well, on the other hand it gives me some time to reintroduce the 64 bit version of the bench. PS: Yes, this is not really an invalid result, just a test.

The speed differences seem to be possible by the 64 bit support, that was available in 1.2 Beta. I removed it because it made no sense for graphics cards. Well, I can reintroduce it, the code path is still built into the new version. I bet GPUPI 2.x with 64 bit support will be faster than the old beta versions too. But I am a bit worried because we will end up with a lot of executables, which is not very rookie friendly: GPUPI.exe (CUDA + OpenCL support) GPUPI_CUDA.exe (only CUDA support - not really necessary, only if OpenCL support would avoid starting the bench) GPUPI_OpenCL.exe (only OpenCL support - necessary for Windows XP) GPUPI_GT200.exe (compiled with CUDA toolkit 6.5 for CUDA 2.0 support of Geforce 200 series cards) GPUPI_64bit.exe (64 bit for fastest CPU support)

Have a look at the log file "GPUPI.log" right next to the executable. Does it say anything more specific? Reasons for this error can be an unstable network connection or an unstable system.

The resulting hex digits are wrong because the card was not stable during the run. The message box shown right after run also indicates that. It's a bit difficult to see in this case, that's why GPUPI 2.1 will show a watermark in the output window to distinguish between valid and invalid results.

Crossfire/SLI doesn't matter in GPUPI. You don't have to enable it and there is no need for the bridges.

What's the problem? The short bench time?

Under 4 seconds? Damn! Your score shows that you really only have to focus on the graphics cards, even on crazy setups with 4x Hawaii. Btw, have you tried setting the maximum clock frequency for each card separately? It should help you to further improve your score.

With CUDA 7.0 NVIDIA removed the support for Geforce 200 cards. GPUPI 1.4 should still work, because it comes with CUDA 6.5 which allows to compile kernels for CUDA 2.0 devices, for example the GTX 285. I would not have introduced a new CUDA version if it wasn't the best for performance. If it's popular I can compile GPUPI 2.1 with the old CUDA toolkit especially for Geforce 200 cards. Btw, here is a full list of currently supported devices: https://developer.nvidia.com/cuda-gpus

GeForce 8 and 9 both support the first versions of CUDA, but I guess I would have to write a whole new code path to support them. It would definitely be _very_ slow. OpenCL 1.0 specifications were release in 2008 so any cards before that have no support. That sadly includes HD 38xx cards that have been launched in November 2007. Although there is one chance to support them with the first version of AMD's Stream SDK and the Close To Metal interface. I tried that years ago without any luck. HD 4xxx are the first cards to introduce OpenCL 1.0. They should work if the recent Catalyst drivers still support them. With old drivers you could run into the "Invalid result" error due to their many bugs with double precision calculation.

It could also be a driver issue. The bench only detects what the driver knows. If a device is ignored (no double precision support), you will be notified in the output window when starting GPUPI. Edit: Have a look at your screen again ... GPU-Z also claims no OpenCL support for this card.

I've just finished working on GPUPI 2.1. It's now in the hands of the HWBOT staff to test it thoroughly! Changelog: Fixed timer bugs in Windows 8/10 - it uses RTC for XP and 7 and QPC (+ validation of frequency) on 8/10. Additionally the used timer and frequency/precision is written to the top of the output window. The data file can now be saved to disk. Detects ~50 AMD graphics cards now (about 30 more than 2.0). Supports UNICODE file paths for logging and configuration now Fixed hardware detection of Xeon CPUs

HD 3xxx series does not support OpenCL.

HWBOT does not know the processor you are using. Please contact the moderators to add it. I have also enabled the manual submission again, I hope that's okay with the HWBOT staff. It has to stay enabled for good because there will always be cases where the detection fails. It's just not possible with the amount of hardware out there, lots of exceptions and inconsistencies ... sometimes even the vendors have inconsisent naming schemes. I highly doubt that it's possible to avoid those detection problems.

It's currently not possible, but will be very soon. Hopefully today or maybe tomorrow. It's is currently tested. I was not aware until today that the manual submission for the bench was disabled. I will talk to Massman about this, because it avoids submission of older AMD graphics cards like HD 58xx, which are currently only detected with their GPU codename and will therefor not be recognized by the HWBOT API.

Great efficiency! hideo, no not really. But it's needed to be able to install the latest drivers Catalyst drivers that include AMD's OpenCL driver. They are currently the fastest ones available, even on Intel platform.

Awesome score for GTX 980 on water cooling!

Seems like the driver is too old. Update it to the newest one and it will work. What's your CPU? Strange error, seems like your system has some general problems. The benchmark needs to create a few (worker) threads by using _beginthreadex(). It's a very basic task for a Win32 application so this should work on a healthy installation. But have a look at GPUPI.log in the directory of the bench, it might give you more insight.

First dual socket score! Interesting to see that OpenCL only shows one device with all the cores. I thought it would be possible to select each CPU separately.

That one is on AMD. They only pass a code name to the OpenCL drivers which is obviously the same for these reused chips. I tried to divide those cards by using the reference gpu frequency of the old models and let everything else be detected as the newer ones. So if you don't have a reference card or flashed it with another BIOS you'll get an R7/R9 card for now. I might be able to distinguish these better by using WMI or a graphics API to read out the family string (HD 7900 series ...) and use it as a helper. Actually I am already using WMI for the HWBOT device detection, if it's needed. But I am not sure if the whole benchmark should be depending on having WMI installed and the service available on the system.