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/av_cuda >>> >> (yes, it's messy). >>> >>> >> Thanks, >>> >>> >> Antony >>> >>> -- >>> Antony Vennard >>> >>> Web Address:http://vennard.org.uk/ >>> OpenPGP Key:http://vennard.org.uk/keys/arv_gmail.asc >> > >> > > > > -- Sent from my mobile device Antony Vennard [email protected] --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
