![]() |
[QUOTE=frmky;560193]
Using ./gpuowl -prp 6972649 -b1 1500000 -b2 10000000 -maxAlloc 4.5G [/QUOTE] Thanks! I pushed a fix, should be fine now. The problem was affecting P2 where the number of buffers was > 1024, which was the case for this small exponent. |
Yes, that fixed it.
2020-10-18 12:36:19 Tesla K20c-0 6972649 P2(1.5M,10M) Setup 1024 P2 buffers in 3.7s ... 2020-10-18 12:38:35 Tesla K20c-0 6972649 GCD: 11352967935560261207067499316137 |
P-1 on known factors
Now with the new version, removing the standalone P-1, could you fulfil last wish from version 6.x, that being, implement the functionality, that when you write known factor(s) in the worktodo line, it will not stop P-1 when finding the already known factor(s) after the first stage? I don't know as much about C and OpenCL as you, but I think you will agree, it can be solved with a simple condition and some extension of parsing script. (If the factor found in P1 consists of only the known factor(s), ignore it, and let the P2 run - or something similar)
And to the new version, do you plan to make PRP-CF available? |
[QUOTE=Viliam Furik;560236]Now with the new version, removing the standalone P-1, could you fulfil last wish from version 6.x, that being, implement the functionality, that when you write known factor(s) in the worktodo line, it will not stop P-1 when finding the already known factor(s) after the first stage? I don't know as much about C and OpenCL as you, but I think you will agree, it can be solved with a simple condition and some extension of parsing script. (If the factor found in P1 consists of only the known factor(s), ignore it, and let the P2 run - or something similar)
And to the new version, do you plan to make PRP-CF available?[/QUOTE] No plans for PRP-CF. I don't have a good understanding of that need myself, and I think that need is adequately covered by mprime. Could you explain a bit more about what you're trying to do by not stopping P-1 when it finds a factor? About accepting a factor in the worktodo line, that was the case before (the factor was completly ignored), but it turned out that was a problem because some users assumed that PRP-CF must be supported because the worktodo line with a factor is not rejected. Now it's rejected for hopefully less confusion. |
[QUOTE=preda;560240]No plans for PRP-CF. I don't have a good understanding of that need myself, and I think that need is adequately covered by mprime.[/QUOTE]
Well, but the mprime or Prime95 can't run on Radeon VII or any other GPU whatsoever. [QUOTE=preda;560240] Could you explain a bit more about what you're trying to do by not stopping P-1 when it finds a factor?[/QUOTE] Simply the same mechanics as in Prime95/mprime. When you create a line in worktodo.txt for P-1, and you include the known factors at the end like this -> [I]Pminus1=AID,1,2,prime,-1,99,0,"factor,factor"[/I] , it will ignore the factors if they are found. gpuOwl 6.x doesn't accept the factors, so it will always stop after first stage if a factor is found. |
[QUOTE=preda;560240]About accepting a factor in the worktodo line, that was the case before (the factor was completly ignored), but it turned out that was a problem because some users assumed that PRP-CF must be supported because the worktodo line with a factor is not rejected. Now it's rejected for hopefully less confusion.[/QUOTE]
In what version was it available? I might just use it if I find the right .exe file. |
[QUOTE=Viliam Furik;560243]In what version was it available? I might just use it if I find the right .exe file.[/QUOTE]
I think any v6.x accepts factors at the end of the assignment, and completely *ignores* them. Does not read them, does not handle them in any way, as if they weren't there. Does not continue P-1 past them, P-1 works in the same way as if the factors were not there. Not very useful IMO. |
[QUOTE=preda;560244]I think any v6.x accepts factors at the end of the assignment, and completely *ignores* them. Does not read them, does not handle them in any way, as if they weren't there. Does not continue P-1 past them, P-1 works in the same way as if the factors were not there. Not very useful IMO.[/QUOTE]
What is the specific syntax needed? Prime95 style is not working. |
[QUOTE=Viliam Furik;560246]What is the specific syntax needed? Prime95 style is not working.[/QUOTE]
I don't know, maybe only works for PRP. Anyway I consider that (not rejecting factors at the end) a bug. |
[QUOTE=Viliam Furik;560246]What is the specific syntax needed? Prime95 style is not working.[/QUOTE]None. Gpuowl has never supported PRP cofactor tests, or known factors in PRP or P-1. V6.11 ignored the additional input, including nonsensical extra input, in a test on PRP.
[URL]https://www.mersenneforum.org/showthread.php?p=558573&highlight=cofactor#post558573[/URL] [URL]https://www.mersenneforum.org/showthread.php?p=556524&highlight=cofactor#post556524[/URL] Gpuowl does a lot, but not everything that mprime/prime95 do, or that we users wish it would do. |
Proof v2
In a recent commit (tagged v7.1), GpuOwl switched to "Proof v2".
This is a change in the way the proof is generated -- slightly different residues are used. Not much changes client-side, except that the transition between proof versions *can't* be done half-way through the PRP test (because: different residues are used for the two versions). So finish the PRP test with the old version, and start a new one with the new version. The "Proof v2" is already accepted (and preferred) by the server, and is the same format Prime95 uses. |
| All times are UTC. The time now is 05:16. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.