We have the same problem here with a 980Ti running on windows 7, with the same drivers and mumax version. Should I try recompiling with the latest CUDA & mumax?

from 3.

mumax3, although linked against cuda6.5, uses PTX code complied with recent
versions of CUDA to properly support Maxwell-based GPUs. This weird
approach is due to the bug in cuFFT provided in CUDA7+. So I guess what
happened is that minimizer was merged after the commit where I've updated
PTX code. If somebody is willing to compile and test, I can update the
entire PTX code?

On 2 November 2015 at 11:27, Callum Vincent [email protected]
wrote:

We have the same problem here with a 980Ti running on windows 7, with the
same drivers and mumax version. Should I try recompiling with the latest
CUDA & mumax?

—
Reply to this email directly or view it on GitHub
#51 (comment).

Mykola

from 3.

I'll do the compilation. I'll have a go at getting the current version compiled now on our windows machine.

from 3.

Thank you very much kahlos. If it works please let us know.

:)

from 3.

I'm busy for the rest of today, but with my morning I've managed to compile everything except the main mumax executable. Below is the output from the compilation. @godsic Any ideas what the problem is? Is it just the gcc.exe: The filename or extension is too long.? Is there an easy way to fix this?

F:\mumax-build>go get -u -v github.com/mumax/3/...
github.com/mumax/3 (download)
github.com/barnex/fftw (download)
github.com/barnex/matrix (download)
github.com/mumax/3/test
github.com/mumax/3/util
github.com/mumax/3/cuda/cu
github.com/mumax/3/timer
github.com/mumax/3/cuda/curand
github.com/mumax/3/freetype/raster
github.com/mumax/3/data
github.com/mumax/3/oommf
github.com/mumax/3/svgo
# github.com/mumax/3/cuda/cu
F:\mumax\src\github.com\mumax\3\cuda\cu\context.go:5:18: fatal error: cuda.h: No
 such file or directory
 //#include <cuda.h>
                  ^
compilation terminated.
github.com/mumax/3/dump
# github.com/mumax/3/cuda/curand
F:\mumax\src\github.com\mumax\3\cuda\curand\generator.go:3:20: fatal error: cura
nd.h: No such file or directory
 //#include <curand.h>
                    ^
compilation terminated.
github.com/mumax/3/gui
github.com/mumax/3/httpfs
github.com/mumax/3/mag
github.com/mumax/3/draw
github.com/mumax/3/script
github.com/mumax/3/prof
github.com/barnex/fftw/internal/double
github.com/barnex/fftw/internal/float
github.com/mumax/3/cmd/mumax3-convert
github.com/barnex/matrix
github.com/mumax/3/cmd/mumax3-httpfsd
github.com/mumax/3/cmd/mumax3-plot
github.com/mumax/3/cmd/mumax3-script
github.com/mumax/3/cmd/mumax3-server
# github.com/barnex/fftw/internal/double
F:\mumax\src\github.com\barnex\fftw\internal\double\kernel_kalloc.c: In function
 'fftw_kernel_malloc':
F:\mumax\src\github.com\barnex\fftw\internal\double\kernel_kalloc.c:91:6: warnin
g: implicit declaration of function 'memalign' [-Wimplicit-function-declaration]

      p = memalign(MIN_ALIGNMENT, n);
      ^
F:\mumax\src\github.com\barnex\fftw\internal\double\kernel_kalloc.c:91:8: warnin
g: assignment makes pointer from integer without a cast [enabled by default]
      p = memalign(MIN_ALIGNMENT, n);
        ^
# github.com/barnex/fftw/internal/float
F:\mumax\src\github.com\barnex\fftw\internal\float\kernel_kalloc.c: In function
'fftwf_kernel_malloc':
F:\mumax\src\github.com\barnex\fftw\internal\float\kernel_kalloc.c:91:6: warning
: implicit declaration of function 'memalign' [-Wimplicit-function-declaration]
      p = memalign(MIN_ALIGNMENT, n);
      ^
F:\mumax\src\github.com\barnex\fftw\internal\float\kernel_kalloc.c:91:8: warning
: assignment makes pointer from integer without a cast [enabled by default]
      p = memalign(MIN_ALIGNMENT, n);
        ^
go build github.com/barnex/fftw/internal/double: gcc: fork/exec f:\win-builds\bi
n\gcc.exe: The filename or extension is too long.
go build github.com/barnex/fftw/internal/float: gcc: fork/exec f:\win-builds\bin
\gcc.exe: The filename or extension is too long.

from 3.

• maybe I am wrong, but gcc should not be invoked at all. try go1.5.1.
• 'fatal error: cuda.h: No such file or directory' means go cannot find the
  header file specified; look at the 'cuda/cu/cgoflags.go' file for the list
  of supported CUDA paths (actually those are default paths CUDA installer
  suggests). I would suggest you to use 'CUDA6.5 for Maxwell' as the only
  rock solid release for Maxwell (if it is still downloadable).

On 2 November 2015 at 12:59, Callum Vincent [email protected]
wrote:

I'm otherwise engaged today, but with my morning I've managed to compile
everything except the main mumax executable. Below is the output from the
compilation. @godsic https://github.com/godsic Any ideas what the
problem is? Is it just the gcc.exe: The filename or extension is too
long.? Is there an easy way to fix this?

F:\mumax-build>go get -u -v github.com/mumax/3/...github.com/mumax/3 (download)github.com/barnex/fftw (download)github.com/barnex/matrix (download)github.com/mumax/3/testgithub.com/mumax/3/utilgithub.com/mumax/3/cuda/cugithub.com/mumax/3/timergithub.com/mumax/3/cuda/curandgithub.com/mumax/3/freetype/rastergithub.com/mumax/3/datagithub.com/mumax/3/oommfgithub.com/mumax/3/svgo

github.com/mumax/3/cuda/cu

F:\mumax\src\github.com\mumax\3\cuda\cu\context.go:5:18: fatal error: cuda.h: No
such file or directory
//#include <cuda.h>
^
compilation terminated.github.com/mumax/3/dump

github.com/mumax/3/cuda/curand

F:\mumax\src\github.com\mumax\3\cuda\curand\generator.go:3:20: fatal error: cura
nd.h: No such file or directory
//#include <curand.h>
^
compilation terminated.github.com/mumax/3/guigithub.com/mumax/3/httpfsgithub.com/mumax/3/maggithub.com/mumax/3/drawgithub.com/mumax/3/scriptgithub.com/mumax/3/profgithub.com/barnex/fftw/internal/doublegithub.com/barnex/fftw/internal/floatgithub.com/mumax/3/cmd/mumax3-convertgithub.com/barnex/matrixgithub.com/mumax/3/cmd/mumax3-httpfsdgithub.com/mumax/3/cmd/mumax3-plotgithub.com/mumax/3/cmd/mumax3-scriptgithub.com/mumax/3/cmd/mumax3-server

github.com/barnex/fftw/internal/double

F:\mumax\src\github.com\barnex\fftw\internal\double\kernel_kalloc.c: In function
'fftw_kernel_malloc':
F:\mumax\src\github.com\barnex\fftw\internal\double\kernel_kalloc.c:91:6: warnin
g: implicit declaration of function 'memalign' [-Wimplicit-function-declaration]

  p = memalign(MIN_ALIGNMENT, n);
  ^

F:\mumax\src\github.com\barnex\fftw\internal\double\kernel_kalloc.c:91:8: warnin
g: assignment makes pointer from integer without a cast [enabled by default]
p = memalign(MIN_ALIGNMENT, n);
^

github.com/barnex/fftw/internal/float

F:\mumax\src\github.com\barnex\fftw\internal\float\kernel_kalloc.c: In function
'fftwf_kernel_malloc':
F:\mumax\src\github.com\barnex\fftw\internal\float\kernel_kalloc.c:91:6: warning
: implicit declaration of function 'memalign' [-Wimplicit-function-declaration]
p = memalign(MIN_ALIGNMENT, n);
^
F:\mumax\src\github.com\barnex\fftw\internal\float\kernel_kalloc.c:91:8: warning
: assignment makes pointer from integer without a cast [enabled by default]
p = memalign(MIN_ALIGNMENT, n);
^
go build github.com/barnex/fftw/internal/double: gcc: fork/exec f:\win-builds\bi
n\gcc.exe: The filename or extension is too long.
go build github.com/barnex/fftw/internal/float: gcc: fork/exec f:\win-builds\bin
\gcc.exe: The filename or extension is too long.

—
Reply to this email directly or view it on GitHub
#51 (comment).

Mykola

from 3.

I do have go1.5.1 installed and running. As far as I can tell, gcc is invoked to compile the fftw code; it is listed as a dependency in the 'releases' section.

I'll take a look at the cgoflags as you suggest and try CUDA6.5 if I have any more problems.

from 3.

Then I would suggest you to check your mingw installation. 'memalign'
function is a part of stdlib for a while, so it should not trigger any
problems.

On 2 November 2015 at 13:12, Callum Vincent [email protected]
wrote:

I do have go1.5.1 installed and running. As far as I can tell, gcc is
invoked to compile the fftw code; it is listed as a dependency in the
'releases' section.

I'll take a look at the cgoflags as you suggest and try CUDA6.5 if I have
any more problems.

—
Reply to this email directly or view it on GitHub
#51 (comment).

Mykola

from 3.

8d67f79

Please 'git pull origin master' or use 'Download ZIP' on the github page.

from 3.

@godsic: the *_53.ptx files are missing from this commit. Could you add them please? Also, I'd like to keep at least *_20.ptx and *_30.ptx unchanged (at language version 4.0, not 4.3) so people with old drivers can run something. I'd be glad to revert those files, but I need your 53.ptx to do that.

from 3.

@barnex oh fuck, sorry for breaking the old ptx stuff and not attaching the new
one. Let me sort this out.

On 7 November 2015 at 21:13, Arne Vansteenkiste [email protected]
wrote:

@godsic https://github.com/godsic: the *_53.ptx files are missing from
this commit. Could you add them please? Also, I'd like to keep at least
*_20.ptx and *_30.ptx unchanged (at language version 4.0, not 4.3) so
people with old drivers can run something. I'd be glad to revert those
files, but I need your 53.ptx to do that.

—
Reply to this email directly or view it on GitHub
#51 (comment).

Mykola

from 3.

No worries, it's not like this made it into the release. We could probably use some testing or automation for this anyway, since I made the same mistake several times before.

from 3.

@barnex do you think it is legal to attach ptx files to the project? At the moment it is a bit hard to keep old/new ptx together behind the scenes. So it would be nice if you can commit the 3.9 ptx'es and then I will commit updated cc50, cc52 and cc53.

from 3.

@godsic: what exactly do you mean by 'legal'?
Anyway, I agree it is a pain to keep the ptx files checked in. We can probably experiment with not having them in the repo and see how that goes. But anyway the ptx content will still be inside .go files....

from 3.

@barnex Well Nvidia always has some strange licenses forbidding
distribution of things. The reason I've asked is that ptx are not
checked-in at the moment. So generating new wrappers relying on mixed ptx
versions is a bit problematic.

On 7 November 2015 at 22:23, Arne Vansteenkiste [email protected]
wrote:

@godsic https://github.com/godsic: what exactly do you mean by 'legal'?
Anyway, I agree it is a pain to keep the ptx files checked in. We can
probably experiment with not having them in the repo and see how that goes.
But anyway the ptx content will still be inside .go files....

—
Reply to this email directly or view it on GitHub
#51 (comment).

Mykola

from 3.

Oh, sorry, I got confused there. Yeah, we can check-in our ptx files so we can collaboratively compile for a different cuda version. As far as I understand the cuda terms of use, this is legally OK. For the moment I only have nvcc 6.5, so I can only generate ptx 4.0. Having ptx 3.x would be nice though...

from 3.

shit I completely missed this commit 9e4efd8 So I will download 6.0 and sort things out myself.

from 3.

Cool, thanks. Keeping the older ptx versions around lets people with old
drivers (like me, because of steam) still enjoy mumax...

On Sat, 7 Nov 2015, 21:43 Mykola Dvornik [email protected] wrote:

shit I completely missed this commit 9e4efd8
9e4efd8
So I will download 6.0 and sort things out myself.

—
Reply to this email directly or view it on GitHub
#51 (comment).

from 3.

Sure. Supercomputers and clusters are also quite conservative about
drivers. So I am planning to use cuda55 for cc2.0, cuda6.0 for cc3.0,
cuda6.5 for cc3.5 and cuda7.5 for 5.0, 5.2 and 5.3. Is it OK?

On 7 November 2015 at 22:56, Arne Vansteenkiste [email protected]
wrote:

Cool, thanks. Keeping the older ptx versions around lets people with old
drivers (like me, because of steam) still enjoy mumax...

On Sat, 7 Nov 2015, 21:43 Mykola Dvornik [email protected] wrote:

shit I completely missed this commit 9e4efd8
<
9e4efd8

So I will download 6.0 and sort things out myself.

—
Reply to this email directly or view it on GitHub
#51 (comment).

—
Reply to this email directly or view it on GitHub
#51 (comment).

Mykola

from 3.

Sounds great, thanks! It's up to you whether or not we check in the PTX
files, I have no strong feelings about that.

On Sat, 7 Nov 2015, 22:01 Mykola Dvornik [email protected] wrote:

Sure. Supercomputers and clusters are also quite conservative about
drivers. So I am planning to use cuda55 for cc2.0, cuda6.0 for cc3.0,
cuda6.5 for cc3.5 and cuda7.5 for 5.0, 5.2 and 5.3. Is it OK?

On 7 November 2015 at 22:56, Arne Vansteenkiste [email protected]
wrote:

Cool, thanks. Keeping the older ptx versions around lets people with old
drivers (like me, because of steam) still enjoy mumax...

On Sat, 7 Nov 2015, 21:43 Mykola Dvornik [email protected]
wrote:

shit I completely missed this commit 9e4efd8
<

9e4efd8

So I will download 6.0 and sort things out myself.

—
Reply to this email directly or view it on GitHub
#51 (comment).

—
Reply to this email directly or view it on GitHub
#51 (comment).

Mykola

—
Reply to this email directly or view it on GitHub
#51 (comment).

from 3.

9c790a8
850daaa
985edfc
a005263

from 3.

Nice, thanks @godsic!

from 3.