[QUOTE=ET_;440986]Anybody tested mfaktc for the 980? smile:[/QUOTE]

Yes.
5 weeks ago I reseted my old GTX760 with a GTX980.
After getting GPU-ECM to work I made a (successful) doublecheck with CudaLucas (v2.05)
and now I'm running tf-work (up to 75 bit) for GPUto72 with mfactc (v0.21).
No problems until now.

Matthias

Woohoo! Found the reference. See owftheevil's post. The GTX 460 is CC 2.1.
[QUOTE=kladner;441236]
I recently tried again to find settings that would work on my MSI 580.

Meanwhile, the faithful Gigabyte 460 is OC to 833 MHz core, RAM clocked down to 1700. It has churned out a 40.9M DC every 3.5 days for weeks, with perhaps one mismatch, which I haven't checked back on. It never does the timeout thing.[U][B] Is that only 580s?[/B][/U][/QUOTE]
[QUOTE=owftheevil;394530]Here's what I know about the bug.

It hangs during a cufft call.
[U][B]It is specific to compute 2.0 cards.[/B][/U]
It is most likely not a problem with cufft:
cuftt4.2 with Nvidia driver 295.?? works
cufft4.2 with >30?.?? drivers show the bug


In Linux, we can recover by resetting the device inside CUDALucas.


In Windows, the devices are deactivated after the timeout
so instead of continuing merrily on our way, we get that
memory allocation error you are seeing. CUDALucas needs
to be restarted to continue.
[COLOR=#000000][FONT=sans-serif]
[/FONT][/COLOR][/QUOTE]

[QUOTE=MatWur-S530113;441353]Yes.
5 weeks ago I reseted my old GTX760 with a GTX980.
After getting GPU-ECM to work I made a (successful) doublecheck with CudaLucas (v2.05)
and now I'm running tf-work (up to 75 bit) for GPUto72 with mfactc (v0.21).
No problems until now.

Matthias[/QUOTE]

So we are no more stuck to CUDA 6.5

[QUOTE=ET_;441621]So we are no more stuck to CUDA 6.5[/QUOTE]

I'm not absolutely sure. As I said, I reset the Hardware, not the Software.
In my CudaLucas folder 3 dll's are stored:
cudart32_42_9.dll
cudart64_42_9.dll and
cudart64_55.dll
and the 3 correspondending cufft*.dll's
I *think* that cudart64_55.dll is used and it works good.
I attache the benchmarks for the 980 and my old 760 (final)

[QUOTE=MatWur-S530113;441827]I'm not absolutely sure. As I said, I reset the Hardware, not the Software.
In my CudaLucas folder 3 dll's are stored:
cudart32_42_9.dll
cudart64_42_9.dll and
cudart64_55.dll
and the 3 correspondending cufft*.dll's
I *think* that cudart64_55.dll is used and it works good.
I attache the benchmarks for the 980 and my old 760 (final)[/QUOTE]
What version are your drivers?

[QUOTE=henryzz;441838]What version are your drivers?[/QUOTE]

GPU-Z reports
10.18.13.6881 WHQL (ForceWare 368.81) / Win10 64

The device-manager shows ~ 25 dll's used by the GC...

[QUOTE=MatWur-S530113;441855]GPU-Z reports
10.18.13.6881 WHQL (ForceWare 368.81) / Win10 64

The device-manager shows ~ 25 dll's used by the GC...[/QUOTE]

Recent enough to support Pascal then.

I have compiled CUDALucas with CUDA8. I'm not sure if there is any point to CUDA8 for me when I have a Titan Black with compute capabilities 3.5.

In the makefile I should use:
SMCODE += --generate-code arch=compute_35,code=sm_35

even though CUDA8 supports up to compute capabilities 6.1, right?

[QUOTE=ATH;443949]I have compiled CUDALucas with CUDA8. I'm not sure if there is any point to CUDA8 for me when I have a Titan Black with compute capabilities 3.5[/QUOTE]

The compute capability is a property of the GPU architecture. If it only has 3.5, then it doesn't matter if the software itself is capable of working with other GPUs that have higher compute capability numbers.

I compiled it and it seemed to run a lot faster but alas it does not work. It fails the selftests and the error variable stays at 0.0000.

Anyone can compile a CUDA8 version? I'm just curious.

According to my experience compiling Titan Blacks, you have to scale back to Cuda 5.5 or even 5.0 in order for a sucessful compile with non zero errors. Not sure about Cuda 6.xx/7xx.