gpuOwL: an OpenCL program for Mersenne primality testing

[kriesel]

Originally Posted by kruoli

Okay, thank you for the information! Somehow I thought, there has been working LL in the past, but I guess, I confused it with CudaLucas etc.

A few LL ran fine without any errors and matched (e.g. M57234283), but others went erroneous (e.g. M57234167, M57234179, M57233941, M55233941).

I uploaded the full logs and residue folders (I guess, that's what they are) compressed for both cards I ran it on here.

Very early gpuowl (before v0.7) implemented LL only, on AMD only. They are limited in fft length and so limited in exponent.One had Jacobi check which is 50% error detection probability. See https://www.mersenneforum.org/showpo...39&postcount=4

Great job sharing logs etc for diagnostic use.

[kruoli]

Originally Posted by kriesel

Great job sharing logs etc for diagnostic use.

Uhm... Thank you? If you are sarcastic: The logs are in the link of my post.

Originally Posted by kruoli

...here.

[S485122]

Originally Posted by kruoli

...
If you are sarcastic
...

Not sarcastic, just paternalistic.

Jacob

[kriesel]

Originally Posted by S485122

Not sarcastic, just paternalistic.

Jacob

Neither. Just sincerely appreciative of people who help the coding wizards improve the software. The more the better, in my opinion.

[kriesel]

This is for the moment, the latest commit available.
Untested except for help output.

[kriesel]

Originally Posted by kruoli

No, I have not tuned at all, because I did not saw such an option in the "-h" menu. Maybe a bit foolish...

For the tuning controls, look in the top of the source file gpuowl.cl, or in the "use flags list" text file I've started including in the .7z files I occasionally post, whichever is most convenient.

[kriesel]

Originally Posted by preda

Do you have another GPU of the same model that does not exhibit such errors? otherwise I'd suspect something amiss software-side (i.e. gpuowl, and the related OpenCL compilation).

Quick update / recap on that;
two rx550s showed the issue, in one pcie slot of one system, while the system's ram fan was underperforming and ram was getting as hot as 100C. After fan replacement reduced ram temps by about 25C, EE errors were still occurring. Then I powered the box down again to move it to the floor, and resumed still with the second rx550 in place. In 5 days of running since, finishing one ~95M exponent PRP and part of another, zero EE have appeared. So I think the case for it being a software issue is weak. The move to the floor only lowered temps about 1C. Ram temps are currently 65-70C. (Higher than other systems of the same model with different cpu and gpu models installed; well within the 95C or higher Micron ram max operating temp spec.)

[Prime95]

Note to all Linux users. If you are changing to the latest commit (recommended), upgrade to rocm 3.3.

[kruoli]

Originally Posted by kriesel

This is for the moment, the latest commit available.

For this build, I got:

gpuowl-win.exe -prp 228479
2020-05-01 22:22:51 gpuowl v6.11-272-g07718b9
2020-05-01 22:22:51 Note: not found 'config.txt'
2020-05-01 22:22:51 config: -prp 228479
2020-05-01 22:22:51 device 0, unique id ''
2020-05-01 22:22:57 Intel(R) HD Graphics 630-0 228479 FFT: 128K 256:1:256 (1.74 bpw)
2020-05-01 22:22:57 Intel(R) HD Graphics 630-0 Expected maximum carry32: 00000
2020-05-01 22:22:57 Intel(R) HD Graphics 630-0 using long carry kernels
2020-05-01 22:22:57 Intel(R) HD Graphics 630-0 OpenCL args "-DEXP=228479u -DWIDTH=256u -DSMALL_HEIGHT=256u -DMIDDLE=1u -DWEIGHT_STEP=0x9.8f139e459cfc8p-3 -DIWEIGHT_STEP=0xd.640310ad3754p-4 -DWEIGHT_BIGSTEP=0x9.837f0518db8a8p-3 -DIWEIGHT_BIGSTEP=0xd.744fccad69d68p-4 -DPM1=0  -cl-fast-relaxed-math -cl-std=CL2.0 "
2020-05-01 22:23:16 Intel(R) HD Graphics 630-0 OpenCL compilation in 19.11 s
2020-05-01 22:23:16 Intel(R) HD Graphics 630-0 Exception gpu_error: INVALID_BUFFER_SIZE clCreateBuffer at clwrap.cpp:285 makeBuf_
2020-05-01 22:23:16 Intel(R) HD Graphics 630-0 Bye

[kriesel]

Originally Posted by kruoli

For this build, I got:

gpuowl-win.exe -prp 228479
2020-05-01 22:22:51 gpuowl v6.11-272-g07718b9
2020-05-01 22:22:51 Note: not found 'config.txt'
2020-05-01 22:22:51 config: -prp 228479
2020-05-01 22:22:51 device 0, unique id ''
2020-05-01 22:22:57 Intel(R) HD Graphics 630-0 228479 FFT: 128K 256:1:256 (1.74 bpw)
2020-05-01 22:22:57 Intel(R) HD Graphics 630-0 Expected maximum carry32: 00000
2020-05-01 22:22:57 Intel(R) HD Graphics 630-0 using long carry kernels
2020-05-01 22:22:57 Intel(R) HD Graphics 630-0 OpenCL args "-DEXP=228479u -DWIDTH=256u -DSMALL_HEIGHT=256u -DMIDDLE=1u -DWEIGHT_STEP=0x9.8f139e459cfc8p-3 -DIWEIGHT_STEP=0xd.640310ad3754p-4 -DWEIGHT_BIGSTEP=0x9.837f0518db8a8p-3 -DIWEIGHT_BIGSTEP=0xd.744fccad69d68p-4 -DPM1=0  -cl-fast-relaxed-math -cl-std=CL2.0 "
2020-05-01 22:23:16 Intel(R) HD Graphics 630-0 OpenCL compilation in 19.11 s
2020-05-01 22:23:16 Intel(R) HD Graphics 630-0 Exception gpu_error: INVALID_BUFFER_SIZE clCreateBuffer at clwrap.cpp:285 makeBuf_
2020-05-01 22:23:16 Intel(R) HD Graphics 630-0 Bye

Congratulations, you can apparently run mfakto on the hd630 because the Intel OpenCL is working. (But it does not have DP and OpenCL2.0, which gpuowl requires.)

Run gpuowl-win -h to see the program generated help, which lists the detected available opencl devices by number and model description, and fft specifications.

[kruoli]

In that case, it would be nice if the program reports that.

-device <N>        : select a specific device:
 0  : Intel(R) HD Graphics 630- not-AMD
 1  : Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz- not-AMD

The program lists both my processor and its integrated graphics as valid devices, even though none of them work (the CPU gives a lot of OpenCL errors while kernel compilation).

I'm just trying out and thought that the program should give proper feedback when used on unsupported hardware. That could be realized by calling clGetPlatformInfo (for reading out the OpenCL version) and clGetDeviceInfo (with parameter CL_DEVICE_DOUBLE_FP_CONFIG) and checking that information.