I think the paths are correct now so make check will pass with a plain C file in add_n.cu . I have only done enough so that this passes , , I've not done the mpf dir for example. We really need some genuine working cuda code , no matter how slow. And all the paths etc are hardcoded for now.
Jason On Saturday 31 October 2009 00:43:25 Jason Moxham wrote: > wrong dir > > try cuda-stuff > > On Saturday 31 October 2009 01:37:56 Antony Vennard wrote: > > Excellent, I've finally got internet again. > > > > I've grabbed svn from > > http://modular.math.jmu.edu/svn/mpir/mpir/branches/mpir-cuda/, when I > > run ./configure --build=CUDA on that svn pull, I get just linking to > > generic, I don't have the cuda file; indeed grep "cuda" * in the src > > folder turns up nothing, am I behind on svn commits? > > > > In theory, CUDA should execute C that is passed to it. There are > > separate functions for allocating memory and things, so, my add_n.cu > > simply has extern "C" prepended to mp_limb_t add.... I was going to try > > building that and see where the library failed to understand which bits > > of C require re-writing. In short, no I haven't got anything working on > > CUDA yet, that's why I was trying to learn the build system, to allow me > > to experiment... > > > > if you've got access to cuda1, have a look in > > /usr/local/cuda_sdk/projects/cppIntegration, this is how the SDK > > recommends integration of CUDA source / C app (/library). > > > > Anyway, thanks for your help on this! > > > > Antony > > > > Jason Moxham wrote: > > > Hi > > > > > > ./configure --build=cuda-unknown-linux-gnu --disable-shared && make > > > now builds with > > > > > > config.status: linking ./mpn/generic/add_1.c to mpn/add_1.c > > > config.status: linking ./mpn/cuda/add_n.cu to mpn/add_n.cu > > > config.status: linking ./mpn/generic/sub.c to mpn/sub.c > > > > > > although the file itself (add_n.cu) is some random cuda junk. > > > If we put a real usefull cuda file in the directory then it may work :) > > > Do we have a demo one ? even if its slow and only partially right. > > > > > > The shared build is a simple matter of not passing -fPIC , and the lib > > > paths could be wrong , and ten billion other things. > > > > > > Jason > > > > > > On Wednesday 28 October 2009 02:21:15 Jason Moxham wrote: > > >> svn branches cuda-stuff > > >> build with > > >> ./configure --build=cuda-unknown-linux-gnu > > >> make > > >> > > >> put *.cu in mpn/cuda directory > > >> > > >> Doesn't actually build with *.cu files yet , probably missed something > > >> simple , anyway I must sleep > > >> > > >> Still need to add linker paths as well > > >> > > >> Jason > > >> > > >> On Tuesday 27 October 2009 18:32:36 Antony Vennard wrote: > > >>> Sorry i've been out of contact everyone, new job and house move this > > >>> week, no broadband until thursday night. On the up side it may be > > >>> fast broadband. > > >>> > > >>> Yes please if you could, at least so i can understand how it's done. > > >>> Have pulled a load of documentation on openmp too so if that requires > > >>> the same thing i'll be able to do it, if not well hopefully i'll work > > >>> out another solution. > > >>> > > >>> Finally, not urgent, i won't be able to update my repository until > > >>> thursday. > > >>> > > >>> Thanks, > > >>> > > >>> Antony > > >>> > > >>> On 10/27/09, Bill Hart <[email protected]> wrote: > > >>>> Yes, definitely do that. From another email I see Antony is waiting > > >>>> for that. And I think it is a good first step. Maybe we wont do that > > >>>> as a final solution. But who knows. It might work well for us. Let's > > >>>> try it and see. :-) > > >>>> > > >>>> Bill. > > >>>> > > >>>> 2009/10/26 jason <[email protected]>: > > >>>>> Hi > > >>>>> > > >>>>> I have been a bit busy of late , so do you still want me to do what > > >>>>> I suggested , tarbox doesn't have a working autotools , so I will > > >>>>> have to do it on my machine and upload it. > > >>>>> > > >>>>> I have just found this > > >>>>> > > >>>>> http://www.bealto.com/mp-gpu_mem.htm > > >>>>> > > >>>>> which has gone some GPU stuff > > >>>>> > > >>>>> Jason > > >>>>> > > >>>>> On Oct 22, 2:25 am, Antony Vennard <[email protected]> wrote: > > >>>>>> Hi Jason, > > >>>>>> > > >>>>>> Ok, that's what I thought but I thought I'd ask. I'm happy to > > >>>>>> check out from subversion of that's easier, or just apply a patch > > >>>>>> I don't mind. > > >>>>>> > > >>>>>> I like git because I can set up a branch that tracks Bill's Selmer > > >>>>>> repo, which is in turn tracking svn, and merge those updates into > > >>>>>> what I'm doing easily, plus if I type git diff brancha..branchb I > > >>>>>> get a patch just like that, so I can see the changes being made > > >>>>>> easily. This can probably be done with subversion, I've just never > > >>>>>> been exposed enough to it. > > >>>>>> > > >>>>>> I've set up and built the cuda_sdk examples on cuda1 on > > >>>>>> tarbox.org, they're in /usr/local/cuda_sdk, in particular > > >>>>>> /usr/local/cuda_sdk/projects/cppIntegration shows you how c/c++ > > >>>>>> and cuda integrate and the appropriate makefiles how they build. > > >>>>>> In brief, it seems that nvcc processes all .cu files which are run > > >>>>>> on the gpu, gcc everything else and the two are linked as > > >>>>>> normal... as such, I think we merely need to produce .cu versions > > >>>>>> of any algorithm code which should then compile in. It may take > > >>>>>> more than that though, hence why I was trying to work out the > > >>>>>> build system to test it... > > >>>>>> > > >>>>>> I'm currently working on my local copy of mpir (not on cuda1) but > > >>>>>> I could move it up there if that's easier? > > >>>>>> > > >>>>>> Thanks > > >>>>>> > > >>>>>> Antony > > >>>>>> > > >>>>>> Jason Moxham wrote: > > >>>>>>> On Wednesday 21 October 2009 21:40:33 Antony Vennard wrote: > > >>>>>>>> Hi All, > > >>>>>>>> > > >>>>>>>> I've been trying to get my head around how to attack CUDA and > > >>>>>>>> MPIR and bring the two together. So far I've come up with doing > > >>>>>>>> the following: > > >>>>>>>> > > >>>>>>>> 1) mpn implementation should be in mpn/cuda. This folder has, > > >>>>>>>> essentially, a copy of "generic" but with things like add_n.c > > >>>>>>>> implemented in add_n.cu (or it will have). This bit I think > > >>>>>>>> makes sense > > >>>>>>>> 2) This bit not so. I added --enable-cuda as an option to > > >>>>>>>> configure, which is fine and dandy, BUT, config.status links to > > >>>>>>>> the x86_64 code, which is correct. The question is, do we treat > > >>>>>>>> cuda as a cpu type? It effectively is... being where the > > >>>>>>>> processing will be done, if so, do we > > >>>>>>>> rely on the user setting ./configure --host=cuda or something? > > >>>>>>>> 3) I thought, from my original plan, of editing the Makefile in > > >>>>>>>> mpn to only include compiler options and rules for %.cu.o and > > >>>>>>>> nvcc and all the > > >>>>>>>> cuda-related stuff if --enable-cuda was set. However... this > > >>>>>>>> isn't what > > >>>>>>>> I'm now thinking. > > >>>>>>>> > > >>>>>>>> Thoughts on this anyone? Sorry, still trying to get my head > > >>>>>>>> around the build system a little... but I think changing the > > >>>>>>>> host type, modifying config.status to link mpn/cuda to mpn as > > >>>>>>>> needed and change the appropriate makefiles is the way to go. > > >>>>>>>> Think, that is... > > >>>>>>> > > >>>>>>> I'm not sure if its the best long term solution , we will have to > > >>>>>>> see how it > > >>>>>>> all works out , but to get going I can think of no easier way. It > > >>>>>>> may be > > >>>>>>> easier for me to add in a new cpu type rather than try to explain > > >>>>>>> how to do > > >>>>>>> it. It will take me longer to figure out the new git system. > > >>>>>>> > > >>>>>>> If I set up a new cpu "cuda" , I dont know how to autodetect it , > > >>>>>>> but we can > > >>>>>>> force any build with ./configure --build=cuda-unknown-linux-gnu , > > >>>>>>> ideally -- > > >>>>>>> enable-cuda could force this build (or autodetect) , this would > > >>>>>>> set mpn-paths > > >>>>>>> and compiler options (at least for gnu/gcc) . I am assuming we > > >>>>>>> are only x86_64 > > >>>>>>> based , which even if we are not it will do to get started. > > >>>>>>> Adding rules for > > >>>>>>> cuda compiler should be straightforward once we have an example > > >>>>>>> cuda file and > > >>>>>>> how to compile it. Are you using "cuda1" on tarbox ? > > >>>>>>> > > >>>>>>> Jason > > >>>>>>> > > >>>>>>>> NB if you just want to look at some of my changes, try > > >>>>>>>> http://vennard.org.uk/gitweb/?p=mpir.git;a=shortlog;h=refs/heads > > >>>>>>>>/a v _c uda (yes, it's messy). > > >>>>>>>> > > >>>>>>>> Thanks, > > >>>>>>>> > > >>>>>>>> Antony > > >>>>>> > > >>>>>> -- > > >>>>>> Antony Vennard > > >>>>>> > > >>>>>> Web Address:http://vennard.org.uk/ > > >>>>>> OpenPGP Key:http://vennard.org.uk/keys/arv_gmail.asc > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en -~----------~----~----~----~------~----~------~--~---
