GPUPI 2.2 Important Update Released and Available for Download (Mandatory Soon!)

The GPUPI benchmark is a brainchild of Matthias from Overclockers.at. It requires CUDA or OpenCL capable hardware and features a fantastic integration with the HWBOT rankings. The benchmark is getting more and more used by overclockers and reviews, so continuous improvements and bug-fixes are welcome. Version 2.2 features a couple of important updates and will be mandatory for HWBOT validation in the near future.

Changelog:

  • - Progress bar for the submission upload including the possibility to abort
  • - Split submission into two dialogs: Online submission and data file saving (will make more sense in future releases)
  • - Timeout set to 30 seconds for reaching the HWBOT servers (in case they are down)
  • - Better file names for data files
  • - Bugfix for Windows XP timer bug
  • - Improved timer validity check and added Skylake's 24 Hz HPET resolution
  • - Better error reporting for OpenCL context creation
  • - Added platform vendor name (if necessary) to OpenCL ready message to better distinguish the platform that a run was started with
  • - Fixed possible cheating in slowest result competitions by aborting a run when system is set to sleep mode/li>
  • - Added execution states to the calculation thread to avoid sleep mode/hibernation (monitor will still be able to go into sleep mode, but that won't affect the benchmark run)
  • - Bugfix for repeated online submission and hardware detection via COM queries
  • - Legacy version uses CUDA toolkit 6.5 again, because 6.0 could not calculate valid results on serveral old graphics cards due to a precision bug
  • - Compiled with newest Visual Studio 2013 - Update 5

In a brief section, Matthias also talks about some upcoming plans for GPUPI. Firstly, there's upcoming integration with CPU-Z which will feature improved hardware detection. This could possibly mean GPUPI will be a major option for low-clock challenges. Also planned is improved support for HWBOT competitions, similar to what the HWBOT Prime for Android currently offers with direct submission to competitions from the benchmark application.

You can find all relevant information and download links at the Overclockers.at news article!


46

France Taloken says:

Nice !

Can you give us a date about when it will be mandatory ?

Belgium Massman says:

We're discussing internally at the moment. There should be a public announcement tomorrow.

Netherlands Spiedie says:

Can this be after the Team cup slowest GPUPI stage? as a lot of people are running days long GPUPI runs that would become useless. Or should we cancel those runs now and start with 2.2 as these changes are specifically against cheating in this stage?

Austria _mat_ says:

No, that's not necessary. GPUPI 2.2 indeed fixes a bug for these slowest result competitions, but it's nothing that can't be moderated manually. Although we will have a good look at slowest results made with GPUPI 2.1.x in the currently running team cup stage. That's for sure. ;)

Vietnam Gia Bao says:

If it use Microsoft visual Studio 2013.I think c# or c++ some thing

Christian Ney says:

We will make it mandatory after the Team Cup is over.

Czech Republic trodas says:

Glad to hear that. Mine GPUPI will be going on for next 12 to 16 days by this "speed": http://s10.postimg.org/bj97gk6yx/GPUPI_93h_11m_too_slow.jpg

Romania Bruno says:

Quote from Matt's website (from release of GPUPI 2.2): "Thanks to HWBOT we will integrate CPU-Z in the next version, which will improve hardware detection a lot and <B>allows several frequencies and even voltages</B> to be automatically submitted to the HWBOT database".
So the next version (2.2X or 2.3) will register CPU/GPU frequency and voltages in real time, and submit them to HWBot db?

Belgium Massman says:

That's the plan

Romania Bruno says:

So now it doesn't record the CPU clock and voltage?

Belgium Massman says:

Not from CPU-Z input, correct.

Czech Republic trodas says:

...makes me wonder, if that version will have the redrawing problem on "starved" CPU as well, as the v2.1.2:


Austria _mat_ says:

As you can see this is not a part of the changelog. That's because your problem is not reproducible, neither on my test systems nor in the source code itself. I can only guess, but it seems like a memory instability that has altered the output buffer. There is also a slim chance that this is a windows GUI bug or a driver bug, but I doubt that. Has anyone else ran into this problem? If yes, please let me know.

Czech Republic trodas says:

Well, if this was a memory error... did not that cause the error in computation alrerady long time ago? It is not like the bench is running for day or so... So I would say that you cannot reproduce that, because you did not run slow-enought for that.

United States xxbassplayerxx says:

The bad thing about GPUPI is that it doesn't stop if there's a calculation error. You won't know until the run is finished. That's why people hate the RedX so much. Bench completes like no big deal but stamps you with an X and it's not valid. Honestly... it should verify after every loop and stop if it's wrong, a la Super Pi.

Czech Republic trodas says:

Absolutely verify after each loop, because if I will wait that long for error run, then that your be a serious heartbreak :( The machine is stable, so, there should not be any error at all... BUT IIRC, the ECC rams are made because there is one bit error for each 0,5MB of ram per month due to cosmic raye or something like that...? So having non ECC rams and performing so long runs (about 366h estiminated, so 15 days and something) is like playing a Russian rulette with the output...

Austria _mat_ says:

xxbassplayerxx said: The bad thing about GPUPI is that it doesn't stop if there's a calculation error. You won't know until the run is finished. That's why people hate the RedX so much. Bench completes like no big deal but stamps you with an X and it's not valid.

Honestly... it should verify after every loop and stop if it's wrong, a la Super Pi.
It's mathematically impossible to do a precise validation on each loop. Otherwise I would have already implemented it, as I think it's frustrating as well. But then I remember how often my system has crashed while taking a screenshot of the result. Well, overclocking can be very frustrating, but that's also a reason why a good score is so worth it. :)

Czech Republic trodas says:

Damn, that is sad... as knowing, if the calculations are or are not valid is paramount to stress testing... I got 324h on the Batch 18, so only two more loops and we know the result... No screen clear now, all results are bellow visible:
Since the 324h mark was hit near end of 26.8., then in about 22 to 23h today I shall be getting Batch 19, so one way or another, this is going to end.

United States xxbassplayerxx says:

_mat_ said: It's mathematically impossible to do a precise validation on each loop. Otherwise I would have already implemented it, as I think it's frustrating as well. But then I remember how often my system has crashed while taking a screenshot of the result. Well, overclocking can be very frustrating, but that's also a reason why a good score is so worth it. :)


Isn't it calculating a known value? And aren't the loops a set length?

Austria _mat_ says:

Yes, the end result is well known, but there are millions to billions of partial results with huge floating point numbers. The loops are completely dependend on the batch size and do not represent fixed points in the calculation. It's even more complex than that, because multiple graphics cards can crunch the batches in any order, so the partial results are async as well. But there is still hope. I have some ideas that could validate at least most of the runs multiple times in between. But it would be optional as it will cost performance to do the checks on CPU calculations. GPU won't be a problem, if the CPU is not the bottleneck.

Czech Republic trodas says:

So, ATM we are left out with only a prayer :) ...but if the checking took valuable CPU time, then version that does it, will be slower... Oh, well... at least this is getting close to the end:
Who have fingers crossed...?

United States xxbassplayerxx says:

;)

Czech Republic trodas says:

My GF recorded her speak-peak if the calculation is done: http://www.youtube.com/watch?v=fr5-_LMSjuM Details on the calculation are there: http://www.youtube.com/watch?v=5vbV6Qc4BhU ...and noticed, that all the times ends with sec 597. That is odd... There is probably something wrong with the seconds mark?

Czech Republic trodas says:

Calculation finished - HWbot ways "Invalid data file: Unable to decrypt the datafile" ... that is a good joke...

Austria _mat_ says:

You are just submitting it to the wrong benchmark category. Be sure to upload it to GPUPI for CPU 1B. Everything else will give you an error. ;)

Czech Republic trodas says:

But I did choose 1B ... oh, wait. CPU 1B! That is the catch. I submited GPU 1B! Sorry then! My bad. All looks okay? http://hwbot.org/submission/2962121_ I made even a video from ending of the run/saving the screen and there are visible redraw problems. Interesed to see?

Austria _mat_ says:

Add it to your submission so the moderators can have a look at it.

Czech Republic trodas says:

Done. The video from saving the score is there: http://youtu.be/F1kM8PG5wHc Note some of the refreshing problems - sometimes everything go missing, lol. But at long, as the score is valid... I try GPUPI 2.2 now :D

Czech Republic trodas says:

Trying GPUPI v2.2 - and looks like I overdid it:
In 30 remaining days, when there will be 38h 43min per loop (2323min x 19 = 735.61h = 30.6days), it migth be necessary to end the CPU load at loop 18 or so and God forbid the loops become slower after the first few ones... _mat_ should i expect the loops getting notably slower later, as before with v2.1...?

Austria _mat_ says:

Same performance. And it will be much more than 30 days, because the first loop is always a fast loop.

Canada Rasparthe says:

Just turn off your Prime95 before competition comes to a close to end it quickly, well and pray that there isn't a power outage.

Czech Republic trodas says:

_mat_ - I was affraid you say that :( We see, how much first faster runs there will be... to compare with previous run, of course. If the speed run on the end will be necessary, then I must pray that I make it right... I mean... disable the CPU load in the right time. Sadly the times at the end will then be weird (eg. not linear). I did not like that, but what can I do now, when I overshoot it... Rasparthe - I use there copies of CPU-Z + priority settings. Seems that I overdid it and the end will be "speedrun" finishing for deadline. If power fail, well, so the score :) I would be more worried about the Aquamark score. Running since 13.8. and from 5200 frames it drawn 3120-something now. That will be interesting result, lol :) And that took me PLENTY of work to achieve. Far more complicated that the GPUPI.

Czech Republic trodas says:

Looks like the starting loops will took around 38h to go:
I wonder, if after the loop 4 it get again to be like almost 5x slower: http://s30.postimg.org/y72p5nt8h/GPUPI_batch_6_48h_wtf.jpg First 4 loops are roughly per 3h each, then it get to 14h for each loop. If that applies on same HW (just less CPU time now), then 38 x 4.666 is 177h (7,3 days!!!) per one single loop... That would be, well... very very *VERY* slow?

United States xxbassplayerxx says:

All going to end in .997?

Czech Republic trodas says:

Previously it was mostly in .597, see the galery there: http://s923.photobucket.com/user/ax2cz/library/GPUPI I'm not reponsible for any timing quirks that are present and as you can see, I can slow down GPUPI even more, so... no idea why it is like this. I did not do absolutely anything to get this weird end timings. But in this score: http://hwbot.org/submission/2962121_ ...I get the .597 ends of each loop since loop 5 till loop 19. Don't ask me why, because I did not know. The first 4 loops was faster, 3h ones. Since loop 5 it started to be around 14h... till the end. Might have to be related? No high precision timer. And redrawing quirks are there present as well. But the output file is valid and calculations are good, witch is IMHO what matter. Don't you agree?

Austria _mat_ says:

Enable the HPET timer if available and try again, it should give you more precise timing. Have a look at the FAQ on the download site for further instructions.

Czech Republic trodas says:

Dunno, if the ASRock 775i65G even support that, but I probably have it disabled if it does support :) So, without HPET the last fractions of seconds should be discarded / considered as bogus, right?

Austria _mat_ says:

No, not at all! RTC is precise enough to capture all categories that are listed on the bot, otherwise I would never have allowed it for time measurement. Your strange loop times might be the result of Windows switching between multiple threads, where some have very high priority and others starve to death. Might be the same for the window refreshing in my opinion.

Czech Republic havli says:

Ah, process starvation - my favorite term of thread synchronisation and resource binding.
Best when combined with the Dining philosophers problem. :D

Czech Republic trodas says:

_mat_ -

Your strange loop times might be the result of Windows switching between multiple threads, where some have very high priority and others starve to death.
Hopefully that will be repeated :) I'm anxious waiting for new loops :)
Might be the same for the window refreshing in my opinion.
Most likely. On the screenshot made by GPUPI one can see even the white place, where the window that is asking for the submiting was... so it is gotta be the refreshing problem... Next time I done special - my own - capture first :) And I keep the CPU-Z minimized now, so - hopefully - no more refresh quirks?

Czech Republic trodas says:

And yes, it is repeated:
All times ending with .997 - looks weird :) Who can wonder that people might be suspicious and report such score? But... I did not do anything nonstandard. So hopefully I will not be screwed up for software bugs. The Aquamark wrapper debacle was quite enought for me and the current CPU-Z inability to report correctly my 10.7MHz CPU clock is yet another megafail example... :(

Czech Republic trodas says:

Aaaargh! I just moved a mouse over the GPUPI v2.2 and... all the previous information are GONE now:
So I maintain that there IS a refresh bug. Sorry, _mat_, but it is repeatable :( You see the mouse? It changed to "edit mode" and the texts are gone now. No wonder people would probably complain that this might be a "cheat"... when it is a bug :( Should I move the mouse out of the window...?

Austria _mat_ says:

Sure, it's a bug but it's not related to GPUPI or its code. It uses WIN32 API and there is nothing special about that. You have to experiment for yourself to find the answer you are looking for. I can't do it for you, because the bug is not repeatable on my test systems.

Czech Republic trodas says:

Hmmm, but it is 100% repeatable on my system. Do you have some old AGP system to test on? Moved the mouse outside of the damn window, hoping for the next batch will not be alone on the screen... No wonder that scores with cleared informations like that are looking suspicious for others. Maybe I should have uninstalled the 6800 GT drivers prior just "putting the R 9600 XT there"... Maybe that can contributed too? Still it will make the score looking weird and I will have to include galery link to these previous screens... :( And still people will likely to complain. And rightfully so, when the data is gone!

Austria _mat_ says:

Have you installed the Radeon drivers? If not, the refresh issues could be caused by the software drivers.

Czech Republic trodas says:

Yes, I installed the Radeon drivers. I believe that the refresh issue happen, when I place mouse over the GPUPI window, as the mouse gesture seems to indicate that I can edit the text (witch is not true, but whatever) and then it somehow draw just the new, "editable" part... That is, what it seems to do for me... even that it probably did not make much sense to you, since I do believe you just draw the info into the window. Yet the OS somewhat get the idea of editing. Maybe change the window properties to not editable? Again, the mouse gesture give it away, IMHO... However I can test new beta only after the end of 30.9. ... for obvious reasons.

Please log in or register to comment.