_mat_

That's normal behaviour. There are two different kinds of loops for 1B results. The loops to calculate the partial results until 500M use less precision and are therefor faster. The loops between 500M and 1B have to use 128 bit integer algorithms, which is much slower. This behaviour is repeated for 4 times, so it's like this: fast loops slow loops fast loops slow loops fast loops slow loops fast loops slow loops => result The number of loops that are fast/slow and how slow/fast they actually are is determined by the batch size. But don't worry, the batch size only slows down or speeds up the whole calculation, depending on how the hardware can process the work load (too small and not all cores can be used at once, too big and the hardware is overwhelmed). It will influence the loops, but it's not like fiddling with the batch size will introduce more slow loops. As I tried to explain, the whole calculation time will just be split differently between those loops. That's because the loops, that are show are just a visual thing and do not really show these two different parts of the calculation. Well, a difficult topic, but I hope I could shed some light on this.

Booom! First one under 3 minutes with a six core CPU. Congrats!

Slow it down by running another benchmark in parallel.

:banana:

GPUPI 2.2 is out now! Thanks to the feedback from you guys, I was able to fix a lot of things and improve many others. It will be mandatory to use this version in the future, because there are some important changes to make the bench even more bullet proof. But we will wait until the the currently started competitions have finished, including the Team Cup of course. Last but not least I would like to talk about our next plans with GPUPI. Thanks to HWBOT I can integrate CPU-Z into the next version, which will improve hardware detection a lot and allows several frequencies and even voltages to be automatically submitted to the database. Additionally we are going to include support for HWBOT competitions directly into the online submission dialog. I already have a prototype working, but I didn't want to rush anything. Full changelog and download here: https://www.overclockers.at/news/gpupi-2-2-english

As GENIEBEN already posted, you should be able to install the AMD OpenCL drivers with the APP SDK 2.9.1. I will be at an Intel Technical Workshop in London soon, where one of the topics is parallel processing. Hopefully I can make some contacts to forward our findings to the Intel OpenCL driver team, so the bugs can get addressed properly.

I have looked into this issue now and it seems like your mainboard and OS combination falls back to an invalid and likely bus dependend timer function. That's why the time is skewed. I have already implemented a more secure way to detect issues with the timer to be able to fall back to RTC on XP accordingly. It will be published with the next version of GPUPI.

You can install the AMD APP SDK as well, it should work without an AMD graphics card. Btw, the graphics card is only needed to be able to install the Catalyst drivers. Otherwise the installation quits because there is "no supported hardware" found on the system.

I have debugged this issue and Intel OpenCL drivers are not compatible with Core2Duos and Core2Quads anymore - at least with the drivers version 15.1 and 14.2. It might work with older versions of the SDK, but they are simply not available on the internet. Btw, if you want to downgrade the Intel OpenCL drivers you have to manually delete the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Intel\OpenCL Otherwise the installer will tell you that there is already a higher version installed, even if you have uninstalled it. But there is a solution: The AMD OpenCL drivers that are automatically installed with the Catalyst drivers DO WORK with these old Intel CPUs. Just go with them, it will work. You might have to plug in an AMD card to be able to install the Catalyst drivers though.

lanbonden, the problem is with your OS timer. Have a look at your HPET frequency, it's way out of bounds. Seems like QueryPerformanceFrequency() returns a very wrong value on XP, that GPUPI can't handle at all. Which SP of XP is this? I will have to look into that. A quick solution for you: Disable your HPET timer in the BIOS and it should automatically fall back to RTC.

Then it's a driver issue, because the latest GPUPI has no changes in this regard. skulstation, I will have a look at OpenCL initialization on these old CPUs. Maybe there is a compatibility issue with certain parameters when creating the context.

Nice one! Congrats!

Desktop with Haswell-E and Windows 8 install with upgrade to 8.1. Well, it doesn't matter anyway, because we can not rely on any Windows version that QPC is handled by the HPET. The same goes for Windows 7, but we can rely on RTC there, which can not be skewed. That problem only exists in W8. Has anybody tried RTC on Windows 10? I assume it has the same problems as 8, but we should test it. If Microsoft solved the problem, depending on the timer used, a few benchmarks could be allowed. And GPUPI can fallback on RTC as well. Edit: My copy is currently on its way, I will test it as soon as I've installed it.

It could depend on the hardware/drivers that are installed, like it is the case for Windows 7. On my system it was enabled by default and used as the primary timer by QueryPerformanceCounter().

Although double precision was introduced with the HD 4800 series, it seems like it still does not support it via OpenCL. Maybe it's only a driver bug, but I don't think that the double precision extension was ever implemented for it. I remember these times, OpenCL was not around when the RV770 was launched in 2008 and also after it's first draft in August 2009 it took a while to catch on. Back then ATI/AMD had its own GPGPU languages like Brook and CTM (Close-To-Metal) ... both are no longer supported by the AMD Stream SDK. So I guess you are out of luck with those graphics cards. Btw, I have not given up on the idea to replace double precision with an float emulation mode yet. Let's see what the future brings.

A classic rookie mistake. :celebration:

It's normally enabled by default in Windows 8 as well.

Clarkdale on LHe? WTF, Roman ... so awesome! Any pictures of the session? Would love to share them!

We will have a look at it, thanks.

Have a good one, guys! :celebration:

Legacy version will be compiled with CUDA 6.5 (so GTX 200 series should work again) Improvements to HWBOT submission: Progress bar for online submission, possibility to cancel the process any time, timeout of 30 seconds for reaching the HWBOT servers (in case they are down) Way better name for the data file (ie: GPUPI_1B_20.134s.result) Some minor bugfixes as well

It's a debug result, just ignore it. Couldn't delete the submission myself, I don't know why. Btw, I am currently working on GPUPI 2.1.3.

GPUPI on a tablet? Who would have thought ... awesome!

Sorry for the delay, just came back from my vacation. Errors like these indicate a malformed file or an errornous upload. The submission files are very sensitive because of their encryption. As the browser switch solved your problem I would guess a browser extension got in the way.

Awesome score! Congrats, Roman.