GPUPI - SuperPI on the GPU

[_mat_]

I'm sorry to bring this up again... but despite all efforts Nvidia G200 still refuses to work with GPUPI 2.2 (legacy). Although the error message is different this time.

 

If you manage to fix this issue, I promise to bench all G200 videocards I can find.

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.

Edited August 16, 2015 by _mat_

[_mat_]

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!

[havli]

This is certainly step in the right direction. Now all presets up to 100M works fine @ CUDA . 500M and above however results in this error:

 

 

OpenCL never worked for me, not even in old 1.4 GPUPI. I think you said it is caused by poor nvidia OCL implementation on these old GPUs.

[_mat_]

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

[havli]

Unfortunately, batch size seems to have no effect. I tried 1M, 2M, 4M, 5M, 10M, 20M

Always halt few seconds after "Batch 4 finished". Reduction Size doesn't help either.

[_mat_]

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.

[havli]

Strange - I've just installed 340.52 and OpenCL is still giving me "invalid result" message. GPUPI 1.4 @ CUDA is working fine. GPUPI 2.2 @ OCL = the same as 1.4 @ OCL.

 

2.2 @ CUDA... as I wrote before. Maybe I should try it on clean windows install. Maybe it will help.

[Mr.Scott]

Strange - I've just installed 340.52 and OpenCL is still giving me "invalid result" message. GPUPI 1.4 @ CUDA is working fine. GPUPI 2.2 @ OCL = the same as 1.4 @ OCL.

 

2.2 @ CUDA... as I wrote before. Maybe I should try it on clean windows install. Maybe it will help.

It won't be your OS install.

Said it earlier, this bench is broken.

[_mat_]

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.

[trodas]

 

Help! I know that the point was to go slow, but this is too much! I'm not even in the half and the speed go to like 24-30h per batch. Will that speed stay, or it improve? I did not touched anything... and I will refrain from clicking on the window everagain - I promise!

Edited August 17, 2015 by trodas

[Mr.Scott]

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.

All I want to know is why CPU's that ran on version 1.4 will no longer run on version 2.2.

Are we sacrificing some older stuff to bench newer stuff for compatibility reasons? That's all I'm asking.

You stated before that CPU support shouldn't have changed version to version but clearly it has.

Sorry if you think I'm wasting your time. Just figured you wanted to know. I won't bother you any more.

BTW, I know a little more than you credit me for......not that it mattered anyway.

[Massman]

If you want to know if something changed for compatibility reasons, why not just ask that. Claiming "the bench is broken" is needlessly negative and will of course cause a reaction.

 

Mat's putting a lot of work in this benchmark and it's one of the better ones we currently have at the bot. It wouldn't hurt being a bit more positive in your approach.

 

Anyway, just my 2c.

[JunkDogg]

If you want to know if something changed for compatibility reasons, why not just ask that. Claiming "the bench is broken" is needlessly negative and will of course cause a reaction.

 

Mat's putting a lot of work in this benchmark and it's one of the better ones we currently have at the bot. It wouldn't hurt being a bit more positive in your approach.

 

Anyway, just my 2c.

 

Well technically if it did work and now doesn't, it is "broken". As the dictionary says "Not functioning, not in order" under broken. :lol:

[trodas]

Well, works pretty well to me. I discovered (by my mistake) only one serious bug, the cosmetic bug is, that when you click into the window during bench, you get only the last line of the bench reported on the screen now... but that it is.

 

IMHO it work pretty well, considering how much stuff it have to work... I say it is a small miracle that it does work on variety of different hardware, considering downclocked machines to unsane limits, etc.

[_mat_]

All I want to know is why CPU's that ran on version 1.4 will no longer run on version 2.2.

Are we sacrificing some older stuff to bench newer stuff for compatibility reasons? That's all I'm asking.

You stated before that CPU support shouldn't have changed version to version but clearly it has.

Sorry if you think I'm wasting your time. Just figured you wanted to know. I won't bother you any more.

BTW, I know a little more than you credit me for......not that it mattered anyway.

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.

 

Well, works pretty well to me. I discovered (by my mistake) only one serious bug, the cosmetic bug is, that when you click into the window during bench, you get only the last line of the bench reported on the screen now... but that it is.

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.

[basco]

thanks mat for putting time + effort into this bench.

[trodas]

_mat_ - send details by PM how I exactly slow the thing down...

...and publicaly I can say it seems to be recovering from my clicks:

 

 

So, if I wait so long and it will not validate, them I would be kinda mad (I bet that is understandable, looking at the times need to perform that superslow run...)

[_mat_]

thanks mat for putting time + effort into this bench.

Thanks basco, very much appreciated!

[trodas]

Hoooray! Just there loops to go, at that speed it should be roughly in 3 days finally finished:

 

 

...and we see, if that redraw is just a glitch or priority thing! If I believe, I would say: let's pray.

 

But I don't. I believe in _mat_ and that the validation file will be okay!

[_mat_]

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.

[trodas]

Well... I will first end the system load, then wait and then click on OK after the computation will be done. That way it hopefully will redrawn just fine. I employ my GF to take a cellphone video, so you will see prcisely, what happend.

[havli]

mat,

can you please take a look at this data file? Suddenly I'm unable to submit my results - Invalid data file: Unable to parse the datafile. Similar error shows up when uploading directly from GPUPI.

 

Testing system is:

2x Xeon 5050 (stock, not overclocked)

8GB RAM

Windows 7 x64, HPET on

GPUPI 2.1.2 or 2.2 (both 64bit)

 

http://hw-museum.cz/data/temp/2x_xeon_5050_GPUPI_for%20CPU_100M_02m-14.666s.result

 

Thanks

[_mat_]

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.

[havli]

Strange thing is single CPU setup didn't suffer from this problem.

http://hwbot.org/submission/2959283_havli_gpupi_for_cpu___100m_xeon_5050_4min_21sec_356ms

http://hwbot.org/submission/2959280_havli_gpupi_for_cpu___1b_xeon_5050_56min_40sec_31ms

 

I will try to remove the second CPU to check if GPUPI submit works again.

[havli]

Update:

Single CPU on the 771 platform now results in the same error. Weird, it was working fine two days ago... and I'm not aware of any changes in OS, drivers or other SW.

 

Another PC using Pentium D 945 + windows 7 x64 works just fine. Well, the OpenCL driver is older and I'm running legacy version of GPUPI because of that... still, the "Unable to parse the datafile" error sounds completely unrelated to this.