Re: Mersenne: GIMPS accelerator?
John R Pierce wrote: > The newest Geforce3 chip also has both Pixel Shaders and Vertex Shaders > which are each a SIMD programmable vector processors. The Pixel Shaders > operate on every pixel and generate the actual RGB pixels while the Vertex > Processors operate on the geometry and texture mapping coordinates of the 3D > mesh... I don't know much about these, but pixels are only 8 bits per > component so the pixel processors can't be very wide. Could this help NFS sieving? Ciao, Alex. _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: GIMPS accelerator?
On 15 May 2001, at 22:46, Ken Kriesel wrote: > Among others, I raised the question with George Woltman some time ago. > I trust his judgment that his time is better spent elsewhere. Agreed! > > However, I wonder if there might be some possibilities in trial factoring > there. > That would present the possibility of a factoring screensaver, and an FPU > LLtest, running together on what is nominally a uniprocessor. > > Just speculation, Nice idea (using the fact that trial factoring & screensaver would be almost pure integer work, whereas LL testing is almost pure FP) but with practical difficulties. (1) To get any benefit, you're going to have to bind all that functionality into one thread - because if you are running more than one thread, the OS will schedule the threads independently, throwing away any benefit which might be gained by parallelism. (2) I think there would be serious difficulties in coordinating code between LL testing (time per iteration almost constant, of the order of tens of millions of CPU cycles) & trial factoring (time per candidate very variable, and of the order of hundreds of CPU cycles). I've no idea at all as to how you would usefully squeeze in a screensaver too, but I do think that the code coordination neccessary to parallelize tasks in a single process thread would be very hard to achieve. (3) Though trial factoring places almost no load on the system memory bus or the floating-point execution units, there are other potential bottlenecks within the CPU - in particular, the L1 instruction cache, instruction decoders, instruction pipelines, jump prediction tables & "spare" registers (required for out-of-order execution) - which may well limit severely the amount of factoring work which could be done in parallel with LL testing, without inflicting a significant performance penalty on LL testing. Given that trial factoring is well advanced, implementing a scheme which increases the trial factoring throughput of the project as a whole at the expense of LL testing throughput does not seem to be a good idea. However, if anyone can provide the functionality that Ken suggests without impacting LL testing performance noticeably, I'll be just as grateful as everyone else! Regards Brian Beesley _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: GIMPS accelerator?
-Original Message- From: Gareth Randall <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] <[EMAIL PROTECTED]> Date: 15 May 2001 23:36 Subject: Re: Mersenne: GIMPS accelerator? >Daran, > >This is an interesting piece of lateral thinking that deserves to go further >than I think it actually does. Thank you for taking me seriously. >Essentially, I'm not sure how the operations that a graphics card can >provide, such as line drawing, texture overlaying, raytraced light effects >etc, could be made to implement a LL test or FFT etc which would require >things like bit tests, conditioning branches and loops etc. What you've listed are the functions of a graphics card, each of which will have been implemented through the application of one or more primitive operations. For example, the function of mapping a set of co-ordinates in 3-space onto screen pixels will be implemented by a linear transformation, which will itself be implemented through a number of scalar multiplications. I'm wondering if it might be possible to access any of the available primitive operations without having to invoke a specific card function. AFAICS the problem requires affirmative answers to all of the following questions. 1.Can the hardware theoretically do work useful to GIMPS? 2.Could this be done efficiently enough to be worthwhile? 3.Is it possible to program the hardware to do this work? 4.Would it be possible to read the results back from the card? 5.Is the available technical documentation sufficient for a programmer to be able to implement this? 6.Would the implementation be acceptable to the user? 7.Are the prospective gains to the project worth the programming effort? I suspect the answer to 1 is yes, given how simple the requirements are for a set of primitive operations to be able to universally compute - the Turing machine and Conway's life spring to mind. But we wouldn't waste time programming a hardware Turing machine to do LL tests, even if we had one. An example of a user issue would be if the only way to program the card is to 'flash upgrade' the GPU's on-card firmware. I wouldn't be willing to do that, although I might consider installing a special GIMPS driver, so long as I could uninstall again. >Conceivably additions could be done by superimposing textures and reading >back the resulting frame buffer, but these wouldn't be 64-bit precision >additions! That's all you get with CPU integer arithmetic, but you can build longer ones out of the shorter. >Maybe some form of matrix multiplication could be done by rotating textures >before superimposing? However, I think the resulting calculation efficiency >would be very poor, and may never achieve useful precision. Could you not build an FFT out of Discrete Cosine Transforms? Or build a multiplication from DCTs in some other way? Some cards have hardware support for this. >Also, any code would be very hardware specific, and may only work if the >display was not displaying, say, a desktop. Which would hit 'prospective gains' question hard, since it would not then be useful on Windows machines. >However, if someone could implement it, it could provide the *ultimate* in >Mersenne related screen savers! What you'd see on the screen would be the >actual calculations themselves taking place before your eyes, and with no >overheads for displaying it either! That I did not think of. >Yours, >=== Gareth Randall === Daran G. _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: GIMPS accelerator?
On 15 May 2001, at 18:22, Daran wrote: > GIMPS clients use the spare capacity of the primary processing resource within > any computer:- the CPU(s). But most modern PCs have another component capable > of performing rapid and sophisticated calculations:- the GPU on the graphics > accelerator. Is there any way that the GPU can be programmed to perform GIMPS > processing when otherwise not in use? There are several practical difficulties: (a) GPUs are usually 32-bit, single-precision hardware. Nothing more is needed for graphics displays. Running multiple precision arithmetic using floating-point FFT in single-precision hardware is not very effective; you need about 20 guard bits; with a single- precision manitssa being 24 bits long, you don't have very much left to work with. (b) GPUs run code from ROM. The system as a whole transfers data but not instructions from the main CPU to the GPU through the video card bus connectors. There is no easy way to change the code which runs the processor(s) on the graphics card. (c) Even if the GPU was programmable from the system, there are so many different graphics card controller architectures that writing code that would work nearly universally would involve something close to an impossible amount of effort. And graphics cards keep changing, fast! (d) Don't forget that running a LL test on a 10M exponent involves about 8 MBytes of data storage. This is not a serious problem given the amount of system memory available to most systems capable of completing a LL test on a 10M exponent in a reasonable time, but "robbing" 8 MBytes from the more limited memory available on most graphics cards might well be critical. Regards Brian Beesley _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: GIMPS accelerator?
Among others, I raised the question with George Woltman some time ago. I trust his judgment that his time is better spent elsewhere. However, I wonder if there might be some possibilities in trial factoring there. That would present the possibility of a factoring screensaver, and an FPU LLtest, running together on what is nominally a uniprocessor. Just speculation, Ken _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: GIMPS accelerator?
> This question pops up every once in a while. A few years ago I looked > through a postscript manual wondering how difficult it would be to build a > postscript file that crunched RC5 keys when a printer tried to render it. postscript is essentially forth, after all. Trouble is, most postscript interpreters are pretty damn slow. > The latest bleeding edge graphics cards are programmable to a limited > degree (am I thinking of the ATI Radeon here?) but not nearly programmable > enough, I'm sure. NVIDIA's chips are semi programmable too, but a big hurdle is lack of documentation on the 3D rendering engine. That stuff is trade secret. I *do* suspect you could use the geometry engine (aka "Transformation Lighting and Projection") to do large numbers of fixed point 3x3 vector-matrix dot products with limited precision rather quickly. The question is, how useful would this be? The pipeline is probably such that you load one matrix and "transform" a large number of x,y,z vectors through it at a rather high speed. I'm not sure how useful this primitive would be in doing FFT operations. The newest Geforce3 chip also has both Pixel Shaders and Vertex Shaders which are each a SIMD programmable vector processors. The Pixel Shaders operate on every pixel and generate the actual RGB pixels while the Vertex Processors operate on the geometry and texture mapping coordinates of the 3D mesh... I don't know much about these, but pixels are only 8 bits per component so the pixel processors can't be very wide. I'm also not sure how fast you can get results OUT of the nvidia memory. Typically, these cards have 32-64MB of very high speed dedicated DDR SDRAM, but its optimized for the GPU to write into the memory, and the display refresh engine to read from it, I don't know how fast results could be read back into the host system -jrp _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: GIMPS accelerator?
John R Pierce wrote: > Virtually all GPU's in use today are fixed function hard wired graphics > accelerators. There's no way to use them for general purpose computational > use. Also, there's no APIs, and each chip vendor has a radically different > architecture. Too bad, the idea might also have given us an interesting screen saver as a side effect! :-) Cheers... Russ _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: GIMPS accelerator?
On Tue, 15 May 2001, Gareth Randall wrote: > Also, any code would be very hardware specific, and may only work if the display was not displaying, say, a desktop. > > However, if someone could implement it, it could provide the *ultimate* in Mersenne related screen savers! What you'd see on the screen would be the actual calculations themselves taking place before your eyes, and with no overheads for displaying it either! This question pops up every once in a while. A few years ago I looked through a postscript manual wondering how difficult it would be to build a postscript file that crunched RC5 keys when a printer tried to render it. The latest bleeding edge graphics cards are programmable to a limited degree (am I thinking of the ATI Radeon here?) but not nearly programmable enough, I'm sure. Heck, at least these ideas have a better chance than the guys who want to crack the programming on kids' toys to make them crunch RC5 keys :) jasonp _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: GIMPS accelerator?
We currently use the FPU (floating point unit) which most office software doesn't use. The GPU is hard coded for graphics and not really useful for anything else. --- Daran <[EMAIL PROTECTED]> wrote: > I know very little about computer architecture, so please feel free > to shoot > me down if what follow is complete nonsense. > > GIMPS clients use the spare capacity of the primary processing > resource within > any computer:- the CPU(s). But most modern PCs have another > component capable > of performing rapid and sophisticated calculations:- the GPU on the > graphics > accelerator. Is there any way that the GPU can be programmed to > perform GIMPS > processing when otherwise not in use? If this could be done, then it > would > have the effect of turning every client computer into an > multi-processor > system. > > Regards > > Daran G. > > > _ > Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm > Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: GIMPS accelerator?
Daran, This is an interesting piece of lateral thinking that deserves to go further than I think it actually does. Essentially, I'm not sure how the operations that a graphics card can provide, such as line drawing, texture overlaying, raytraced light effects etc, could be made to implement a LL test or FFT etc which would require things like bit tests, conditioning branches and loops etc. Conceivably additions could be done by superimposing textures and reading back the resulting frame buffer, but these wouldn't be 64-bit precision additions! Maybe some form of matrix multiplication could be done by rotating textures before superimposing? However, I think the resulting calculation efficiency would be very poor, and may never achieve useful precision. Also, any code would be very hardware specific, and may only work if the display was not displaying, say, a desktop. However, if someone could implement it, it could provide the *ultimate* in Mersenne related screen savers! What you'd see on the screen would be the actual calculations themselves taking place before your eyes, and with no overheads for displaying it either! Yours, === Gareth Randall === Daran wrote: > > I know very little about computer architecture, so please feel free to shoot > me down if what follow is complete nonsense. > > GIMPS clients use the spare capacity of the primary processing resource within > any computer:- the CPU(s). But most modern PCs have another component capable > of performing rapid and sophisticated calculations:- the GPU on the graphics > accelerator. Is there any way that the GPU can be programmed to perform GIMPS > processing when otherwise not in use? If this could be done, then it would > have the effect of turning every client computer into an multi-processor > system. _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: GIMPS accelerator?
--- Daran <[EMAIL PROTECTED]> wrote: > I know very little about computer architecture, so please feel free > to shoot > me down if what follow is complete nonsense. > > GIMPS clients use the spare capacity of the primary processing > resource within > any computer:- the CPU(s). But most modern PCs have another > component capable > of performing rapid and sophisticated calculations:- the GPU on the > graphics > accelerator. Is there any way that the GPU can be programmed to > perform GIMPS > processing when otherwise not in use? If this could be done, then it > would > have the effect of turning every client computer into an > multi-processor > system. > > Regards > > Daran G. > > > _ > Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm > Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: GIMPS accelerator?
> I know very little about computer architecture, so please feel free to shoot > me down if what follow is complete nonsense. > > GIMPS clients use the spare capacity of the primary processing resource within > any computer:- the CPU(s). But most modern PCs have another component capable > of performing rapid and sophisticated calculations:- the GPU on the graphics > accelerator. Is there any way that the GPU can be programmed to perform GIMPS > processing when otherwise not in use? If this could be done, then it would > have the effect of turning every client computer into an multi-processor > system. Virtually all GPU's in use today are fixed function hard wired graphics accelerators. There's no way to use them for general purpose computational use. Also, there's no APIs, and each chip vendor has a radically different architecture. -jrp _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers