_mat_

Can you do me a favor please and post a screenshot with open Debug Log (Menu: Tools => Debug Log). Please open the log window before you are saving the result file. Is that possible or is the application instantly closed?

Thanks for the bug reports. It works on Skylake X and Coffee Lake, my primary test systems. Well, lets break out the old stuff then.

GPUPI 3.3.1 Not a day old and already a bugfix release. Download here: https://www.overclockers.at/news/gpupi-3-is-now-official Changelog: Bugfix for kernel compilation on old AMD graphics cards Bugfix for command line mode when using "-a" parameter (optional API selection) Improved error message including a tip when the calculation fails due to the watchdog timer resetting the graphics driver (only happens on old graphics cards when a kernel takes longer than 5 seconds). Improved error message when an OpenCL device runs out of ressources including a tip how to fix it (for example on old AMD graphics cards with reduction size 512) Bugfix for Multi-GPU Mode: If one of the devices abort the calculation due to an error, the benchmark run is now aborted.

English news + downloads: https://www.overclockers.at/news/gpupi-3-is-now-official

Then lets push forward! I love it! A few facts: Due to the less complex calculation code, the comparison between different GPU/CPU architectures and GPGPU APIs (CUDA VS OpenCL) is fairer than it ever was. No extra code for compatibility, just what's necessary to make it run. The improved handling of OpenCL makes better use of the devices (= CPUs and AMD GPUs). That results in less differences between the OpenCL drivers. Plus Batch Size and Reduction Size are not that important than they were before. They are still if you want the golden cup, but beginners won't score as bad if they just click Calculate + Ok. AMD OpenCL 1.2 now trumps everything that Intel has got. Even for 100M on Intel CPUs. The Intel OpenCL drivers suck. AMD OpenCL 2.0 works much better now. It still has problems with bigger reduction sizes like 512 and 1024. Seems like 256 is the best currently. I have just uploaded a version with some last minute fixes for the HWBOT submission (better wording, removed the screenshot canceling). Please download GPUPI 3.3 from here: https://www.overclockers.at/news/gpupi-3-ist-final It's now official!

QFT: "yes lets push forward! make the bench run efficiently...why make it be 7 minutes when it could be 4 minutes. always push forward" Please follow the discussion about GPUPI 3.3 right here:

That's not possible, C++ 2015 is necessary since 2.x. It might just have been installed by another application with an installer. That's definitely not enough information to get anything fixed. Are you opening the normal version with your Q9950? That can result in an OpenCL error, if you don't have an OpenCL 2.x runtime installed. GPUPI would complain about a missing "clCreateCommandQueueWithProperties" function. Old hardware should only use the Legacy version, it supports OpenCL 1.1.

The way I see it as an overclocker, you are beating others by being active and putting more effort into it. I remember Turrican redoing each of his impacted GPU scores with every new CPU generation out there. There is a multiude of other factors that need rebenching as well: Driver updates Tweaks uncovered New OS version Bugfixes and cheat protections for benchmarks I guess it's safe to say, that rebenching is pretty normal to be in the top ranks. Especially in the race for Hardware Masters. That's what I am trying to find out together with all of you. I don't want to overrule things like that, just because I can. I want to make a good decision, that keeps overclockers happy and motivated to bench GPUPI. That's my only goal with the benchmark!

The Visual Studio C++ 2015 Redistributable is needed for the normal version of GPUPI since 2.x. Download is here: https://www.microsoft.com/de-at/download/details.aspx?id=48145 (use the 64 bit version). Btw, the Legacy Version needs the Visual Studio C++ 2013 Redistributable because CUDA 6.5 can not compile on newer version of Visual Studio. Have you tried different settings for the hardware detection? You can try "Safe Mode" first and select "Off" if that doesn't help. I reckon that this is just a compatibility issue with HWiNFO.

I just recompiled GPUPI 3.3 with the old kernel code and the difference is about non-existent for CUDA 32B: GPUPI 3.2: 6m 56.414s GPUPI 3.3b: 6m 56.676s ~200 ms difference is about nothing in a 32B run.

To show you the current evolution of GPUPI 3.1.1 VS 3.2 VS 3.3 I have benched all versions on 2x GTX 1080 Ti @ 1987 MHz in 32B on CUDA. GPUPI 3.1.1: 6m 59.194s (GPU frequency is shown too low, API information is not as detailed as in the other versions) GPUPI 3.2: 6m 56.414s GPUPI 3.3: 4m 37.242s (that's the speedup in question)

The OpenMP path won't happen until the end of the year or maybe even 2019, so we can discuss that at a later point (maybe split the CPU category into GPUPI 3 and GPUPI 4 like GeekBench 3 and 4 is handled). This discussion should be about GPUPI 3.1+3.2 VS the faster 3.3 (in all categories). Btw, GPUPI 3.3 is currently not enabled for HWBOT submission although I have released a few scores for testing.

Please share your thoughts on speedups like this as well, any feedback is appreciated! I'll promise to keep updates like this to a minimum to avoid unnecessary rebenching.

Fair warning: GPUPI 3.3 is now officially available and will give a decent speedup on all calculations. I'd like to clarify the reasons behind this, because I know that means some rebenching might be necessary for the top ranks. It's the first time since GPUPI 1.x that I changed code inside the calculation kernel. Yes, GPUPI had some speed increases before but only because new hardware was officially supported/optimized or new CUDA/OpenCL versions got new features that GPUPI could use for improvements to stay on the edge of what's out there. I am currently implementing a native path for CPUs, that will take advantage of OpenMP and AVX/AVX2. OpenMP needs no extra installation like OpenCL (it's compiled into the application) and will be far more efficient, highly optimizable and all in all faster than any OpenCL implementation for CPUs out there. Last but not least OpenCL is treated badly by CPU vendors and rarely gets updates nor optimizations or fast support for new hardware. With OpenMP I can decide all that for myself and optimize/support any CPU I can get my hands on. Plus GPUPI gets less complicated because no additional drivers will need to be installed. GPUs already get their GPGPU API with the graphics driver (with the exception of Intel's iGPUs) and CPUs won't need anything installed anymore. Just start GPUPI and you are good to go. Bottom point is I want to get rid of OpenCL for CPUs in the long run. To make that happen I needed to slim down the calculation part that handles 128 bit integers to improve vectorization (for AVX support), which ultimately led to the speedup. But why the hell did I decide to release the improved code already with GPUPI 3.3? Because: It resolves a number of compatibility issues that I had since the first release of GPUPI. I had to manually tweak some kernel code for older devices and that's a very time consuming thing. I always want to release the best version of GPUPI that my current abilities allow me to. It's kind of my personal way of overclocking (with code). I had some feedback that GPUPI 3.1 is faster than 3.2 (which can be true for some GPU/CPU combinations) and so people are currently using 3.1, 3.1.1 or 3.2 for results. A fourth version of GPUPI (3.3) with similar speed wouldn't have made the situation easier, neither for maintaing nor for benching. I think it's no fun at all to have to try different versions of the same bench to get the best result. The speedup of 3.3 resolves that, because now there is only one obvious choice. Without further ado, here is GPUPI 3.3: https://www.overclockers.at/news/gpupi-3-ist-final (it's in German for now but there are lots of images ;))

What's your system hardware?

Good idea, thanks for the input!

Yes and I don't like it as well. I don't know why NVIDIA decided to go that way, but I hope that there's a good reason for it. I could compile a CUDA 8 version of GPUPI 3.x of course, but then I have to maintain 3 different versions in the future. I don't think that's a good solution at all as people are already confused with the Legacy Version.

Then it's either a submission to the wrong category (like GPUPI 1B with a CPU score) or some problem with HWBOT and/or the network connection.

You have to install the latest GeForce drivers. You can verify this by opening the debug log (Menu: Tools => Debug Log), there will be an error that states, that your driver is not ready for CUDA 9.x. As an alternative you can use the Legacy Version of GPUPI. It's compatible with older GeForce driver versions, but will most certainly perform worse.

Thanks, that would be very helpful. Please open the Debug Log (Menu: Tools => Debug Log) as well when you are taking the screenshot. There should be a technical description coming from the HWBOT server that provides further information about the submission error. Just to clarify: There is no difference in the HWBOT submission code between GPUPI 3.1 and 3.2. I have heard of the issue and it's most likely a bad network connection or a hiccup of the HWBOT servers while submitting. I don't want to rule out an error on my part though.

I have rewritten the data file saving for GPUPI 3.3 and the skipping of CPU or GPU detections is done in a safer way now. The downloads links will be up soon, so please retest any time. One more side note: David (mllrkllr88) from overclock.net is currently holding a competition with GTX 260s and GPUPI is part of it. I am working closely together with him to fix any bugs the users encounter. The GTX 260 is one of the oldest and slowest cards to run GPUPI plus GPGPU computing was in a very early stage back then when these cards were released, so it is a bit of challenge. Here is the link to the competition: http://www.overclock.net/forum/410-benchmarking-competitions/1675577-freezer-burn-overclocking-competition.html

Hi bolc, thanks for your kind words, much appreciated! Regarding your problems: Can you provide a screenshot for the bad checksum problem please? I need to know the exact error message and where it happens. The crashes due to HWiNFO are hard to completely avoid. There is so much hardware out there, that it's almost certain that something goes wrong when you are testing a lot and especially old components. But every new version gets the latest HWiNFO library, that always comes with a lot of fixes and improvements, so please use the latest version of GPUPI if possible. And if you come across a hardware detection error, please select the "Debug Mode" for detection and post it here together with some information of the hardware, that seems to cause the crash. I will forward it to Martin from HWiNFO, so it will get a chance to be fixed.

Ok, now I understand, what you meant. I thought it happens when you are using the validation functionality on your already saved data file. Have you tried to skip the detection of your graphics card when saving the data file?

Thank you for your bug report. Can you send me the validation file to matthias [at] hwbot.org? I will have a look at it.

Version 3.1+ is now mandatory. The rules are not uptodate. Congrats OGS! Crazy 1080 Ti!