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 <goodwillh...@googlemail.com> 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 <ja...@njkfrudils.plus.com>:
> > >> 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 <antony.venn...@gmail.com> 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
> > >>> >>_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 mpir-devel@googlegroups.com
To unsubscribe from this group, send email to
mpir-devel+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/mpir-devel?hl=en
-~----------~----~----~----~------~----~------~--~---
