_mat_

Invalid result means your hardware is not stable. Even the slightest miscalculation in the first 27 decimals in just one of the billions of partial calculations can output the wrong result. Sometimes I wonder that it even works so well with overclocked cards.

Awesome mixture! Finally somebody is using the flexibility of GPUPI (or GPGPU in general) to get more points.

As I said, GPUPI has no access to clock speeds, let alone manipulate them. But there is of course always the possibility that the OpenCL or CUDA driver of the card is involved in this and enables another speed step, that is not set up correctly. Please post a screenshot of Afterburner showing the problem and a comparison to another windowed 3d application like Furmark. I am sure we can get to the root of this problem.

Those aren't GPUPI specific issues, the software (currently) can't control any of these clock speeds. I guess the downclocking happens on any kind of load, if you measure it in the background with Afterburner.

What batch size are you using?

100M is only for CPU, you are running the benchmark with GPU.

I've uploaded it for you: https://www.overclockers.at/downloads/capture.zip

You have to complete a run using a category that is represented in HWBOT. That is: CPU: 100M or 1B GPU: 1B or 32B All other categories won't allow you to save or submit a validation file. Without HPET you can't complete a benchmark run on Windows 8 or 10. There will be a startup error.

Glad to hear that you got it working! I am currently very busy doing overclocking shows at a local gaming exhibitions, but as soon as I am done, I will compile the latest version with debug symbols and send it to you.

Yes, that could be. And it's also possible that the board is faulty or the BIOS settings introduce these errors. That's why it's so important to test the stability of the system!

Very weird error. Points to either faulty memory or I fucked something up in the code. As the error seems to occur after the last loop (it's just not drawn yet), it will have to do with accumulation of the partial results or the validation of the final sum. Both depend only on system memory, that's why the error happens both on GPU and CPU. The error is not repeatable on my side and was never reported by anyone else, so I guess that your memory is faulty. Try memtest86 and Prime95 with focus on memory for an hour or so and let me know if your system is still stable.

This answer from the FAQ section might help you:

Today I implemented a validation algorithm during runs. It should help a lot to determine invalid partial results way before the final result. I am currently testing the algorithm, but it seems to work fine and will be released with GPUPI 2.3.

Thanks, Frederik! Might be a problem with the windows version. Is this a czech version? Please post a screenshot of your system panel (Control Panel => System).

havli, we will look into this. Thanks for your feedback. Strunkenbold, this is a very old submission with GPUPI 1.3, that was done manually, not via the HWBOT integration. The user made the mistake to enter the wrong calculation time. Please report it to a moderator, it should get fixed or removed.

I have created an internal ticket to find out more about this error. I might be a compatibility issue with your setup, but it's hard to say.

The validation file only avoids photochopping of screenshots and validates the result itself. It does not show irregularities in loops, if you know what I mean. Only GPUPI 2.2 ensures that to 100%. Well, let's see if the screen gets redrawn, but I won't bet on it.

Thanks basco, very much appreciated!

That's completely different than saying that the bench is broken and I am happy to answer it. As I said before, CPU support has not changed at all. The hardware limitations are OpenCL support (which depends on SSE availabilty) and double precision support. So if it's not listed as available device, the installed drivers do not recognise it as device, that can run OpenCL code. If it's listed but ignored because of missing double precision support, it's because the drivers say that dp is not available. In conclusion and as answered a few posts above the limitations depend heavily on the installed drivers, not on the version of GPUPI. I would recommend to install the AMD OpenCL drivers also for Intel CPUs especially on hardware, because they support CPUs since SSE2.x. The Intel drivers only offer support since SSE4.1, which excludes all Pentium 4 models. Seems like that may be the problem that mr. paco posted here. Regarding GeForce 200 series cards, there also have been no deliberate changes to sacrifice compatibility. But there have been changes to the kernel calls to allow multiple GPUs and since then many smaller kernel improvements (mostly performance enhancements) were implemented. That's why the GPUPI 2.2 kernel with high precision exceeds the available registers and shared memory limitations of the GeForce GTX 285. As soon as I get my hands on one of those cards, I will optimize the legacy version to slim the code down. Maybe just for these cards. So the bench is far away from being broken and it would be sad if it would be after all the time that I have invested. These are just driver bugs or certain limitations for old hardware, that I would never have anticapted to work at all. Can anybody reproduce this? I tried with all my test systems and had no luck at all. If I had a guess, I would say that the output buffer was and is deleted because there are memory problems. The clicking just redraws the window, that's all. Let's see if the run turns out valid ... keep me posted please.

And I said earlier as well, Mr Scott, you have little to no knowledge on this topic. Parallel processing is a relatively new technology, especially for these old cards. APIs, drivers and GPUs themselves have bugs and several limitations, which are constantly improved with every generation. I am actually quite impressed that so much old hardware could be successfully benched. So Mr, stop with your over-simplifying oneliner bunnyextraction. It's not appreciated here.

I research some more and the problem seems to be register limitations of these old graphics cards. So the calculation code of the high precision loops is too complex to be successfully processed. To fix this I would have to get myself a GTX 200 series card and restructure the code to use less registers. I might do that, but it will take a while. Btw, OpenCL on GTX 200 series should not be a problem. CatEye (Turrican's sister) benched a GTX 295 on Windows 7 64 bit with GeForce 340.52 drivers. Have you tried that? http://hwbot.org/submission/2776702_cateye_gpupi___1b_geforce_gtx_295_11min_46sec_73ms Please also be sure to only have cudart32_65.dll and cudart64_65.dll next to the GPUPI executable. If you still have cudart32_60.dll etc in there, delete these files.

Try to reduce the batch size step by step. Older cards and implementations do not offer enough resources.

I might have found the issue with old CUDA drivers on GTX 200 series cards! I've updated the download, so please redownload GPUPI 2.2 from here and please try again. Let me know if it works now!

We certainly will get to the bottom of this. Have you tried more recent drivers? The drivers you are using only support CUDA 6.0.5, but the legacy version is now bundled with CUDA 6.5. Please use the newest drivers possible. The 340.52 should work for your combination: http://www.geforce.com/drivers/results/77225 Btw, try to use OpenCL as well. Maybe it works better.

The code in GPUPI itself can not determine the capability of the hardware, that's done by querying OpenCL. So this is a driver issue. Have you tried the same drivers you used last time?