mfakto: an OpenCL program for Mersenne prefactoring

[Jayder]

st2 passed perfectly. CPU usage at 0.6%. Would it be fine for me to use this version and report results with it?

[Bdot]

Originally Posted by Jayder

st2 passed perfectly. CPU usage at 0.6%. Would it be fine for me to use this version and report results with it?

Yes, for me it also passed amost all tests.

The only thing you must not use, is VectorSize=1. But this will fail the minimal selftest too anyway. And for AMD HW, there is no reason to not use Vectors.

Therefore I think it is safe to use this version.

[LaurV]

OK, we are here now:
Windows XP 32 bits SP3 on a Pentium D extreme 3.4GHz, 4G RAM, fresh installation, all updates to the last. Amd Radeon HD 7970 ghz edition from XFX. Drivers 13.1 or 13.9 (both can be installed, not simultaneously, but "disk format" in between, it only takes few minutes for a clean winxp reinstallation). WinXP32 versions, both. None of them seem to install openCL.dll, which is missing when trying to run mfakto. Installing the SDK 2.5, or (alternatively) copying the dll file only, into windows/system32, will let mfakto (0.13, win 32) to run, but it will not be able to detect the GPU. So, every trial to run it without GPU sieving (or completely deleting the mfakto.ini file) will run perfectly but... falling bach to CPU, with only 1 Meg Hz Days per Day or so. Trying to run it with GPU sieving results in this:

mfakto 0.13-Win (32bit build)


Runtime options
  Inifile                   mfakto.ini
  Verbosity                 1
  SieveOnGPU                yes
  GPUSievePrimes            82486
  GPUSieveSize              64Mi bits
  GPUSieveProcessSize       16Ki bits
  WorkFile                  worktodo.txt
  ResultsFile               results.txt
  Checkpoints               enabled
  CheckpointDelay           300s
  Stages                    enabled
  StopAfterFactor           class
  PrintMode                 compact
  V5UserID                  none
  ComputerID                none
  TimeStampInResults        no
  VectorSize                2
  GPUType                   AUTO
  SmallExp                  no
Compiletime options
  MORE_CLASSES              enabled
Select device - GPU not found, fallback to CPU.
Get device info - Compiling kernels.

        BUILD OUTPUT
.\common.cl(31): warning: unrecognized #pragma
  #pragma "Enabling printf"
          ^

.\common.cl(41): warning: unrecognized #pragma
  #pragma "Replacing popcount"
          ^

.\common.cl(91): warning: unrecognized #pragma
  #pragma "Emulating amd_max3"
          ^

.\gpusieve.cl(95): warning: integer conversion resulted in a change of sign
                                    1<<16, 1<<17, 1<<18, 1<<19, 1<<20, 1<<21,

(billions of errors follow). We guess the card is too new for those drivers, and we can not install newer sdk/etc because they are not running on that old OS. There is no way to linux or update the OS to win7 (pentium D, remember?) as this computer is dedicated to other things too.

Any idea? What are we doing wrong, what are we missing?

The card is installed in a PCIe20 slot (yes, this old mobo with socket 775 has a pcie 2.0 slot!), and it runs ok through all the (other, non-mfakto) tests, including gaming, and it can also do scrypt-mining and folding-it without problems, which makes us think that the problem is in mfakto, except for the case we are doing something stupid..

[Bdot]

mfakto's error could be that the package does not include all the OpenCL libs that could be required.
I'm not sure anymore if XP already had a system32 ... but the libs should be:

"c:\Windows\System32\OpenCL.dll", amdocl.dll, amdocl_as32.exe, amdocl_ld32.exe

If these files were not installed by the Cat13.9 installation, then the installation did not succeed. Did it at least install clinfo? It is a prerequisite for mfakto detecting the GPU that clinfo reports it:

C:\Users>which clinfo
clinfo:
        C:\Windows\system32\clinfo.EXE

C:\Users>clinfo
Number of platforms:                             1
  Platform Profile:                              FULL_PROFILE
  Platform Version:                              OpenCL 1.2 AMD-APP (1348.4)
  Platform Name:                                 AMD Accelerated Parallel Processing
  Platform Vendor:                               Advanced Micro Devices, Inc.
  Platform Extensions:                           cl_khr_icd cl_amd_event_callback cl_amd_offline_devices cl_khr_d3d10_sharing cl_khr_d3d11_sharing cl_khr_dx9_media_sharing


  Platform Name:                                 AMD Accelerated Parallel Processing
Number of devices:                               2
  Device Type:                                   CL_DEVICE_TYPE_GPU
  Device ID:                                     4098
  Board name:                                    AMD Radeon HD 5700 Series
...

Maybe it's worth checking the Catalyst installation. It also provides a "manual" option where you can select OpenCL support (selected by default, but ...)

No idea if it is any good ... I took the mentioned files from my syswow64 folder (Cat13.11beta though) and loaded it to box.com. If you put them right next to mfakto, maybe it is loading them and happy with it. Apart from that, I don't have good suggestions.

Well, I did not understand your comment about the processor and Linux. AFAIK, there are still 32-bit-versions of recent distributions (SuSE, for instance), and the kernel dropped 386 support just a year ago ... Pentium probably will be supported a few more decades.

You could also check "the other (successful) tests" (furmark, sandra, ... ?) what their OpenCL test configuration reveals ... BTW, games do not count as they are are not usually using OpenCL (or do you have such a game?).

[kracker]

Just for the record, a Pentium D can run Win7 well or even the hated 8. (it has SSE2) But I know you said you couldn't upgrade anyways. (other things)

Also, no game I know of uses OpenCL atm. (OpenGL/DX)

EDIT: It should run x64 as well, assuming you have enough RAM.

[LaurV]

The as.exe and ld.exe (no numbers in the file names), together with clionfo.exe, are installed into ProgramFiles/AMD_APP/bin/x86, by the AppSDK kit. There is none of them in the system32 folder. The opencl.dll instals there if I install the sdk stuff. Without it, i mean only with the 13-9(or 1)_xp32_dd_ccc_whql.exe installed, there is no clinfo nor opencl. Also, there is no error signalled during installation, and every other applications I can think of except mfakto (I did not try ccLucas yet!) detects and uses the card right. One reason I don't like radeons... Still the nVidia guy. Giving up for now, after 3 days of trials, I don't think there is any stone unturned, beside of going into mfakto sources, which I don't have enough time to do it...

[kracker]

I know (again) that you're stuck with xp for one reason or another... but that probably is your biggest problem. Neither AMD or MS supports it anymore.

[LaurV]

You are very right. After your former message (not the last one) I convinced "the right person" to install win7. (The point was that I was not very convinced myself, but your post made me change my mind - you seemed to know what you are talking about ). Everything ran from the box! I mean, drivers installed, click on mfakto, boom! working. I am currently crunching with 360GD/D with the 7970, on that old mobo and CPU, and is quite amazing responsive, I expected to click and wait hours, but it is not the case. I can not increase the speed of mfakto right now, because Catalyst Control Center does not run yet - same as AMD's MOM, and same as Misfit - CCC and they all need dotNet 4.0 or higher, and the Win7 is still crawling through the list of 138 "important updates" and about 10 or 15 "optional updates" (which I deselected), the .Net is the 100th in the list, or something. (this is normal behavior after fresh reinstallation - the windows update will crawl for few hours till it updates everything "to date" - in this time mfakto is running! [edit: hey! already found a factor!]).

Bad part is that now this computer needs to have always a mouse plugged in, but I found an old one and stuck it in its butt. One reason of using XP was the "synergy" environment, which is only partially running on win7 (for example, you can not click the TechpowerUp's GPU-Z's window with a mouse connected over synergy, on win7, the GPU-Z application is totally invisible for synergy (!?!?) also, in win7 you need first to login to activate synergy, therefore I need now to use no password (otherwise it would need a keyboard too...), etc. One ugly thing is that when you try to install something, win7 will popup a system window asking you if you are sure that you want to change the system folders (or the registry), and (optional) make the rest of the screen black. You may know this behavior, which is not easy (and not safe) to get rid of (it can be canceled if you play wit the local security policies). Well, the system window in cause, is also transparent for the mouse connected over synergy, but not only: after you use a "local" mouse to click that "yes" button, the local synergy is killed (!?!? no joke, the service is aborted!). Well, but that is a different story.

Funny thing: my man is using Christian Ghisler's Total Commander (I corrupted him, I mean my man, some time ago, and I still believe this is the best file browser for windoze). When you change TC's settings, it writes a file called wincmd.ini in C:\windows folder (the program was former called "windows commander", but Microsoft sued the developer for the name - one more reason for me to like this program: it stepped on M$'s toes ). The location of the file can only be specified at installation time, and can not be changed after (only if you edit the files in binary, it is not storred in the registry or else). We have "unlimited" license for it, and because is easier to copy the files (comparing with installation plus applying the lic, etc), we copy the files from another computer every time we do a new installation. Well, the old installation wanted to create the ini into the windows folder. This works well with XP, but it doesn't work with Win7, because it will not allow an "unknown" program (which does not come from a verified installation) to write in the windows folder, unless you don't go to the folder, use right-click, properties, security, and change the security attributes for the folder to allow everyone to write there. Which again, it is not safe... but well... Now imagine my man's face when he started TCmd and saw that he is still seeing the old tabs and folders, from the old computer (which of course were empty here!) every time he starts the program, and not the new folders he had when he closed the program (the program is supposed to remember the status it was when you closed it, when you will open it next time). Very frustrating, you could see it on his face, hehe, but here is my domain...

(since I write this, the dotNet came, it will be installed soon, after the other downloads will come, 62% now, from the total).

[edit: errata on my former post: i wanted to write "clinfo" and not "cloinfo", i just saw it now]

[edit 2: I just tried CLLucas, it is also working fine - for this I only have 64 bit exe, so I could not try it on XP, luckily, otherwise I would spend/waste some hours/days with it too...]

[kracker]

Yes.. first updates are a PAIN. And the computer is a lot slower while it's doing it.

[LaurV]

I might have an (empirical) idea how to make mfakto faster, about two times faster than currently is, at least for some cards.

Facts: my (overclocked, air cooled) 7970, crunching exponents from 47M to 69M, from 69 to 74 bits, here is a small table with GHzDays/Day. These are not (only) the (pre)calculated values given by mfakto, but (also) the (postcalculated) wall-clock real time values. There was also a small "tuning" done for the number of primes, but once established, it was not changed. Can anyone with a HD79xx card confirm the (proportion between the) values?

         
bitlevel   69-70   70-71   70-71   71-72   72-73   73-74
exponent           GHzDays/Day       
  48M       630     610     560     523     488
  52M       638     615     565
  55M                       568     538     503
  62M               615     580     545     503     448
  65M               633     601     550     521     463
  68M               633     601     550     521     463   

So, it is clear that when it deals in smaller chunks for sieving, the card is much faster. Larger chunks do more access to slower common memory. The idea would be to "break" the higher bitlevels in "subbitlevels", for example split the 74 into 4 subranges, "73 to 73+71", "73+71 to 73+72", "73+72 to 73+72+71", and "73+72+71 to 74". This way, the 7970 would achieve 630G in average, instead of 440G in average, as it achieves now.

Remark that we mostly do 64M to 74 bits, therefore using this cart at half of its capacity! I changed all my assignments for this card to maximum 73 bits, and the production overnight jumped 150% (in GHzD/D).

What the hack, this card is 3 times faster for mining compared with a gtx580, and the sha256/scrypt-ing it is not more/less computation hungry than mfakto-ing, this card can give much more for mfakto!

[TheJudger]

Sounds odd to me. Assuming that mfakto works similar to mfaktc than the relative small fractions of the range are processed at once, than the next one and next one until the full range is done. So in fact mfakt[co] is working on "subbitlevels" already.

Oliver