I've finished and uploaded GPUPI 2.1.1 which introduces serveral smaller bugfixes:

 

• Detection of operating system is no longer including language dependend suffixes. (thx to Taloken & COMIAS)
  
• Submission to HWBOT can now be started with an opened result popup "Pi calculation done" (thx to der8auer)
  
• Fixed hardware detection for Core i7 980X/990X/995X and QX9750/QX9770/QX9775.

 

Please test it and let me know if that fixes all current issues.

 

Download: GPUPI 2.1.1

Tested Win7x32.

i7 2700K.

HD 7970.

Good work.

Thank you!

Edited May 12, 201510 yr by sebro

Thanks a lot for the fix Mat, we will test it

 

Another question :

 

I observed, like on this screen (http://img.hwbot.org/u93743/image_id_1405285.jpg), that setting a high batch size reduce the number of loops for a same bench.

It's an expected behavior ? ^^

I've finished and uploaded GPUPI 2.1.1 which introduces serveral smaller bugfixes:

 

• Detection of operating system is no longer including language dependend suffixes. (thx to Taloken & COMIAS)
  
• Submission to HWBOT can now be started with an opened result popup "Pi calculation done" (thx to der8auer)
  
• Fixed hardware detection for Core i7 980X/990X/995X and QX9750/QX9770/QX9775.

 

Please test it and let me know if that fixes all current issues.

 

Download: GPUPI 2.1.1

 

i testet it whit my qx9775 setup.

and its faster.or changing proritie an killing explorer helps

have a api message

Edited May 12, 201510 yr by skulstation

I just want to say that I was running GPUPI yesterday for a demo, and I was impressed by the HWBOT integration.

 

Might be even better than XTU

I observed, like on this screen (http://img.hwbot.org/u93743/image_id_1405285.jpg), that setting a high batch size reduce the number of loops for a same bench.

It's an expected behavior ? ^^

Yes, that's perfectly normal behaviour. It's only possible with 100M and a batch size of 100M. The reason for this is that only 4 batches are sent to the CPU to calculate the result, so the benchmark can't split it up into the usual 20 steps.

 

Thanks Massman! I will introduce a progress bar for submission in the next version, that will make slower uploads more visual. We can also add the mainboard vendor, mainboard name, amount of memory and so. There is still some potential to improve the integration.

does not create a file once completed. no option to save a file at all. and no option to submit. .. .using 2.1.1. . soooo how does one go about submitting this ?? ?

been writing all over and no one has a single response.. . . ..so lame

Might be even better than XTU

 

It is

 

We can also add the mainboard vendor, mainboard name, amount of memory and so. There is still some potential to improve the integration.

 

Will help you there with the stuff from AQ3.

 

been writing all over and no one has a single response.. . . ..so lame

 

Patience.

Edited May 12, 201510 yr by GENiEBEN

does not create a file once completed. no option to save a file at all. and no option to submit. .. .using 2.1.1. . soooo how does one go about submitting this ?? ?

This is not a 24/7 hotline, it's a support thread. I check it about 5 to 6 times a day, but sometimes I am sleeping.

 

About your problem: After a valid run goto to "Submit to HWBOT" in the menu. A new dialog will open and allow you to "Save to file".

 

@ _mat_

 

is it possibel to run it on a non windows platform?

or make it non windows compatibel?

Edited May 16, 201510 yr by skulstation

Yes, it would be possible to implement a version running on any platform that supports CUDA and/or OpenCL, but there are no plans yet. I am currently focusing my time on GPUPI 2.2 which will bring some interesting improvements. Can't promise anything right now.

good to hear thad its possibel but no rush for other platforms,take your time whit the windows version.

plz check the xeon e5506,Validation failed: Processor is required for 2D benchmarks.

Hm, it should be fine. Still an issue?

no issues any more.thx

Noted when I ran it with my 560-448 GPU the validation file when submitted had the submission info boxes open and it showed the card as a regular 560, not a 560-448 and these are indeed different cards.

 

Had to edit the entry once done to place the results into the correct hardware heading. I don't know if that wiped out the validation file or not for the entry but I did submit it and still have it here if needed. There will be a few issues like this I know, just pointing out one here to be worked on or at least to make it known.

 

Another thing is the 6870's are ignored due to the double precision issue so I guess they don't support it. I do have the latest drivers loaded into the OS for it (Omega drivers ver 14.12 with dotnet 45 for Win 7 64 bit). Downloaded the drivers only two days ago and I guess these GPUs would have to be ran with the legacy version - I'll try it and see whether it works or not.

Edited May 28, 201510 yr by Bones

Thanks for your feedback.

 

Seems like the NVIDIA drivers make no difference betweeen GTX 560-448 and a normal one. But the number of Compute Units are different, so I can fix this on my side. It will be included in my next release.

 

HD 6870 lacks double precision support indeed. No chance to run these cards with any version of the benchmark, sry.

I've just updated GPUPI to version 2.1.2. It's a minor release that fixes the detection of AMDs Furys and R9 300 graphics cards.

 

If you have any problems with the release, just let me know. Btw, this is not a mandatory release, all versions >= 2.1 will work for submission.

 

Downloads: GPUPI 2.1.2 (1.06 MB, CRC-32: CB9069F2) | GPUPI 2.1.2 - Legacy Version (Windows XP, GeForce 200 series, 590 KB, CRC-32: 1497D087)

I'm having trouble to run legacy CUDA version of GPUPI 2.1.2 on my GTX 285. The old (discontinued) GPUPI 1.4 works just fine... but the 2.1.2 is giving me "invalid result" error all the time. I can't get even a 32M score (the whole calculation process runs fine but the result seems to be invalid).

And the 1B run aborts just after 2nd batch:

 

 

Log:

LOG START at 2015-07-08  16:31:13 ----------------------
Starting run to calculate 1000000000 digits with 250 batches
Batch Size: 4M
Maximum Reduction Size: 64
Message box: Press OK to start the calculation. (Start)
Error while calculating series term!
Result digits: 000000000
Result time: 41.874000
Device statistics for NVIDIA GeForce GTX 285:
Calculated Batches: 125 of 1000 (12.500000%)
Kernel time: 41.701000 seconds
Reduction time: 0.147000 seconds
Message box: Invalid result! (Error)

Edited July 8, 20159 yr by havli

Thanks for your report! Try 1M and let me know if it's working. The result is invalid because the kernels can not be executed anymore after a certain point. I might have to look at this problem closer.

 

Btw, GPUPI 1.4 uses CUDA 6.5, GPUPI 2.1 uses 6.0. I thought I could improve backwards compatibiltiy with 6.0 by supporting Compute Capabilty 1.2. But these old versions won't allow double precison anyway. Well, I might switch back to CUDA 6.5 for the legacy version, which should fix this problem too.

Thank you for the help - here it is:

 

GPUPI 2.1.2 Legacy - CUDA (1M)

 

LOG START at 2015-07-10  01:07:04 ----------------------
Starting run to calculate 1000000 digits with 1 batches
Batch Size: 1M
Maximum Reduction Size: 64
Message box: Press OK to start the calculation. (Start)
Result digits: 000000000
Result time: 0.191000
Device statistics for NVIDIA GeForce GTX 285:
Calculated Batches: 4 of 4 (100.000000%)
Kernel time: 0.176000 seconds
Reduction time: 0.012000 seconds
Message box: Invalid result! (Error)

 

GPUPI 1.4 CUDA (1M)

 

Also I've noticed the 1.4 has 384 / 448 threads and 2.1.2 has 512 / 512. Perhaps this could be part of the problem?

Same thing here, kinda weird. . .

 

 

havli, as far as I can see it threads and blocks are not the problem here. In the legacy version for CUDA 6.0 my own code decides the occupancy of the GPU, because there is no kernel analyzer function in this version of the CUDA toolkit. Starting with 6.5 such a function was introuduced in CUDA and therefor it is used in GPUPI.

 

The problem here is more likely some bug in the CUDA implementation. Like some really small issue with a double precision function.

 

ls, as said in my pn this is related to stability of your system and not a bug.

havli, as far as I can see it threads and blocks are not the problem here. In the legacy version for CUDA 6.0 my own code decides the occupancy of the GPU, because there is no kernel analyzer function in this version of the CUDA toolkit. Starting with 6.5 such a function was introuduced in CUDA and therefor it is used in GPUPI.

 

The problem here is more likely some bug in the CUDA implementation. Like some really small issue with a double precision function.

 

ls, as said in my pn this is related to stability of your system and not a bug.

 

Stable enough to complete the run, but not stable enough to submit? Hmm.