I got it to work by resetting my computer and not ever trying any other gpu activities like boinc or folding@home. I think it was some sort of weird interaction between things, even though before I had closed the other things.

Jason, are there any plans to add support for ATI GPUs in the future? I think it would be very useful.

With ATI boards I think there are two choices: either do all the CUDA work over again in ATI's pseudo-assembly language, or do all the CUDA work over again in OpenCL and hope that everyone's very immature middleware libraries can manage decent performance. Even though I think there are several people here who would love the result, I doubt I'd have the development time to make much headway. Besides, it's not like the sieving or linear algebra runs on a GPU right now :)

Msieve, GPU and 64-bit Windows 7
 

Here's how I managed to get CUDA and msieve working on an Acer laptop running 64-bit Windows 7. It wasn't entirely trivial and the installation (probably) still isn't perfect. I hope this account may be of use to others, especially as it should hit Google within the next week or so.

The laptop is an Acer Aspire 5739G with moderately nice graphics --- a GT240M with 1GB of video RAM. Therein lies the first problem. According to nVIDIA ([URL]http://www.nvidia.com/object/cuda_gpus.html[/URL]) the GT240M isn't CUDA-enabled. There didn't seem to be a good reason for this so I tried to install the CUDA-enabled driver anyway. No joy. The installer claimed there was no hardware supporting that driver.

Googling turned up [URL]http://forums.nvidia.com/index.php?showtopic=102548&st=120[/URL] which gave the clue required: download the latest driver from [URL]http://www.laptopvideo2go.com/[/URL] together with the modifed nvdm.inf file available there.

Installing the driver was a chore. After a couple of failed attempts I removed the Windows driver and rebooted into VGA mode. All the driver files had been unpacked to a memstick beforehand. Clicking on the setup.exe was successful and, after a reboot, the machine worked properly again.

Next step was to install the 64-bit CUDA toolkit and SDK from nVIDIA. There isn't a specifically named version for Win7 so I downloaded and installed the Vista versions. They seemed to work, in that the SDK examples gave sensible output.

Finally, I downloaded the msieve144_gpu binary given near the start of this thread. Despite being a 32-bit binary, it appears to work on a 64-bit OS when run under Brian's Python script. It is now finding polynomials for a c100 test number. If it finds something, I'll let it complete.

I couldn't find a 64-bit GPU-enable msieve binary. Does such a thing exist? I can't build one myself, yet, because my elderly copy of Visual Studio is 32-bit only.

The msieve binary I am running is rather chatty and is putting out a very large number of lines with the form "poly 0 p <digits> q <digits> coeff <digits>". Is this to be expected, or have I got a hold of a debugging version?

Paul

[QUOTE=xilman;207645]
The msieve binary I am running is rather chatty and is putting out a very large number of lines with the form "poly 0 p <digits> q <digits> coeff <digits>". Is this to be expected, or have I got a hold of a debugging version?
[/QUOTE]
No, it does that for everyone. I need to get a feel for the rate at which the GPU version finds hits, so they're all printed out.

building on RHEL5
 

The stock trunk/Makefile fails to build on a RHEL5 system. Changing this
[code]CFLAGS += -I"$(CUDA_INC_DIR)" -DHAVE_CUDA[/code]
into
[code]CFLAGS += -I"$CUDA_INC_DIR" -DHAVE_CUDA[/code]
makes it work. That is, use the envvar rather than the Makefile variable with the same name.

Please someone check that my version works in other environments, especially Windows. If so, I suggest that the change be made in SVN.


Paul

Does CUDA define different environment variables in RHEL? If it's a conflict between the make variable and an environment variable we could just change the name of the make variable.

If it's the quotes that are the problem, this is kind of a catch-22; the windows environment variable is a windows path with backslashes, which will not work when gcc is called from make. So the quotes are needed.

I guess I can echo the environment variable and run sed to change backslashes into forward slashes.

[quote=jasonp;207744]Does CUDA define different environment variables in RHEL? If it's a conflict between the make variable and an environment variable we could just change the name of the make variable.

If it's the quotes that are the problem, this is kind of a catch-22; the windows environment variable is a windows path with backslashes, which will not work when gcc is called from make. So the quotes are needed.

I guess I can echo the environment variable and run sed to change backslashes into forward slashes.[/quote]CUDA doesn't define any variables by default. I defined those two myself, taking the hint from the comments in the Makefile.

The slash/backslash distinction doesn't appear to be an issue. The modified Makefile still has quotes in it.

Paul

[quote=jasonp;207744]Does CUDA define different environment variables in RHEL? If it's a conflict between the make variable and an environment variable we could just change the name of the make variable.

If it's the quotes that are the problem, this is kind of a catch-22; the windows environment variable is a windows path with backslashes, which will not work when gcc is called from make. So the quotes are needed.

I guess I can echo the environment variable and run sed to change backslashes into forward slashes.[/quote]Does sed exist in Windows? (I know that such as Cygwin supply it).

Perhaps easier would be to require WIN=1 (or the like) to be given as an argument to make --- you could then do pretty much whatever you like thereafter.

Paul

Windows doesn't have an equivalent to sed; both cygwin and minGW do though (actually minGW provides only development tools, and msys supplies actual user stuff like text utilities)

Logorrhoea
 

I'm searching for GNFS polynomials for a C178 using a Tesla C1060, and it is making great progress. However, the program is less than 50 hours into a 300-hour run and the msieve.dat.p file is already 163 megabytes in size. The three largest Murphy_E scores are 7.4{02,77,78}e-14 and these are almost twice the smallest, which are 3.969e-14.

Disk space is plentiful, so I'm not particularly worried on that score. I'm just wondering if there is any easy way of reducing the amount of output in future. Perhaps msieve could retain the top 20 (say) polynomials found in the run so far and only output new ones if they enter somewhere in the top 20.

Would this be worth doing? If so, I may take a look at the code.

Paul