[QUOTE=kruoli;544059]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. [URL="https://www.mersenne.org/report_exponent/?exp_lo=57234283&full=1"]M57234283[/URL]), but others went erroneous (e.g. [URL="https://www.mersenne.org/report_exponent/?exp_lo=57234167&full=1"]M57234167[/URL], [URL="https://www.mersenne.org/report_exponent/?exp_lo=57234179&full=1"]M57234179[/URL], [URL="https://www.mersenne.org/report_exponent/?exp_lo=57233941&full=1"]M57233941[/URL], [URL="https://www.mersenne.org/report_exponent/?exp_lo=55297621&full=1"]M55233941[/URL]).

I uploaded the full logs and residue folders (I guess, that's what they are) compressed for both cards I ran it on [URL="http://mc.oliver-kruse.de/GIMPS/gpuOwl"]here[/URL].[/QUOTE]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 [URL]https://www.mersenneforum.org/showpost.php?p=488539&postcount=4[/URL]

Great job sharing logs etc for diagnostic use.

[QUOTE=kriesel;544081]Great job sharing logs etc for diagnostic use.[/QUOTE]

Uhm... Thank you? If you are sarcastic: The logs are in the link of my post.
[QUOTE=kruoli;544059]...[URL="http://mc.oliver-kruse.de/GIMPS/gpuOwl"]here[/URL].[/QUOTE]

[QUOTE=kruoli;544085]...
If you are sarcastic
...[/QUOTE]Not sarcastic, just paternalistic.

Jacob

[QUOTE=S485122;544086]Not sarcastic, just paternalistic.

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

gpuowl-win v6.11-272-g07718b9 build
 

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

[QUOTE=kruoli;544066]No, I have not tuned at all, because I did not saw such an option in the "-h" menu. Maybe a bit foolish...[/QUOTE]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.

[QUOTE=preda;543924]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).[/QUOTE]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.)

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

[QUOTE=kriesel;544373]This is for the moment, the latest commit available.[/QUOTE]

For this build, I got:
[CODE]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[/CODE]

[QUOTE=kruoli;544405]For this build, I got:
[CODE]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[/CODE][/QUOTE]
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.

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

[CODE]-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[/CODE]

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 [FONT="Courier New"]clGetPlatformInfo[/FONT] (for reading out the OpenCL version) and [FONT="Courier New"]clGetDeviceInfo[/FONT] (with parameter [FONT="Courier New"]CL_DEVICE_DOUBLE_FP_CONFIG[/FONT]) and checking that information.