Setup in new version gets illegal memory access about xmr-stak-nvidia HOT 26 CLOSED

You could try the same config than before with 7 threads and 40 blocks. Or you can change blocks to 10 or maybe 5 and try it again.

from xmr-stak-nvidia.

I've tried. I've even lower it to 1 thread and same problem.
I've recalculate my setup based on this, now I'm getting with old release 195.3H/s or 195.2H/s is it possible to be this stable? With the old config it was scaling from 180 - 200 H/s. Thanks for advices.

New config for old release, not working in the last:

"gpu_threads_conf" : [ 
	{ "index" : 0, "threads" : 21, "blocks" : 15, "bfactor" : 6, "bsleep" :  25, "affine_to_cpu" : false},
],

from xmr-stak-nvidia.

You need to change the parameter blocks not threads. Please try thrads = 32 and blocks = 10.

@fireice-uk Is the windows binary compiled for all compute architectures? 20,30,35,37,50,52,60,61 and 62

from xmr-stak-nvidia.

Same error in the new version, in older release I'm getting 192.3 H/s

from xmr-stak-nvidia.

@psychocrypt it is compiled for 20, 52 and 60. Same story with the old version. Somehow I overlooked 61 and 62 doesn't exist yet afaik. Since each version is a superset of the old ones. Compiling for every single one would produce a mammoth binary, each version takes about 0.5 MB

from xmr-stak-nvidia.

Ahh ok thats the issue, we need to compile for all alchitectures else it is not running everywhere. The binary with all architectures is around 10MiB.
The 860m is sm_30, sm_50 or sm_52 depending of the model.
If you would save space it is possible to build only for the base architectures (sm_X0) but this could cost mining performance.

@fireice-uk Could we create a fix release with new binaries and all architectures? Currently all keplet and some maxwell gpus will not work:(

from xmr-stak-nvidia.

What's causing it not to work? Last time I checked sm_20 code was happily running on a gtx 1070, and the previous version was compiled with exactly same parameters.

from xmr-stak-nvidia.

The virtual assambler (ptx) for maxwell 5.0 and kepler 3.0 (this issue) is not included. The new fermi optimization added shared memory for sm_2x to communicate between threads. The amound of shared memory is defined at runtime depending on the architecture.
@Mattthev system compiles code for his kepler gpu out of the virtual ptx code from sm_20 and than starts the kernel without shared memory because he is using a kepler gpu. This is the reason for this issue.

The binare needs at least support cor 20,30,50 and 60. But you need to take care how you activate the architecture support else it could be that the ptx code is not included.

This is a copy out of my pull request for the windows project file

compute_20,sm_20;compute_20,sm_21;compute_30,sm_30;compute_35,sm_35;compute_37,sm_37;compute_50,sm_50;compute_52,sm_52;compute_60,sm_60;compute_61,sm_61;compute_62,sm_62

from xmr-stak-nvidia.

I have Maxwell 860m, most of 860m are Maxwell architecture.
GPU-Z screenshot

from xmr-stak-nvidia.

@Mattthev Thx for the information. The issue is the same because the ptx sm_50 is also not included.

from xmr-stak-nvidia.

@psychocrypt viral assembler? Is that an autocorrect typo? I would want to get to the bottom of what broke between old and new release.

from xmr-stak-nvidia.

It was a typo, I corrected the original post. It should be virtual.

from xmr-stak-nvidia.

Ok, sounds plausible, but why does the old build work? With the mining performance can you give me a better idea of the penalty - last time I checked running sm_20 on gtx 1070 was around 1-2%

from xmr-stak-nvidia.

The old version not used shared memory, the new one used NULL as pointer to shared memory for all sm >= 30. If the 20 ptx is compiled for this I access the adress NULL. In the old miner the number of blocks was selected by the compute architecture, there was 4 times more threads started in the some case that now is crashing but the kernel have some guards thos the wrong started threads get killed.
The old implementaion for sm_20 was not bad on pascal therefore the performace penalty was not high. But kepler gpus not performe with the old sm_20 code path.

from xmr-stak-nvidia.

Ok If we have a build that has 20, 30, 50, 52, 60 and 61, do you think that's a good compromise?

from xmr-stak-nvidia.

I will try to measure how much of performance we lose if we are not build explicit for all architectures.
I will post the results here.

from xmr-stak-nvidia.

I checked how we can shrink the size of the binary without losing performance: we need only to include the SAS-Code (real assembler code) without the virtual assembler. The virtual assembler(PTX) is the most size consuming part in the binary. Than we could support all architectures.
If the next generation NVIDIA gpu is coming we need to create new windows binaries (but this is not before end 2017 or begin 2018).

Please add this parameter to the visual studio additional CUDA compiler options and leaf the part free were you can add the architectures as pairs.

--generate-code arch=compute_20,code=sm_20 --generate-code arch=compute_20,code=sm_21 --generate-code arch=compute_30,code=sm_30 --generate-code arch=compute_35,code=sm_35 --generate-code arch=compute_37,code=sm_37  --generate-code arch=compute_50,code=sm_50 --generate-code arch=compute_52,code=sm_52 --generate-code arch=compute_60,code=sm_60 --generate-code arch=compute_61,code=sm_61 --generate-code arch=compute_62,code=sm_62     

The parameter --generate-code arch=compute_20,code=sm_21 is not a bug it is the way to build SAS only for sm_21.

The size of the binary without openSSL and microhttp is 6,4MB

from xmr-stak-nvidia.

Please wait before building any binaries I am still testing other combination and the impact to the performance

from xmr-stak-nvidia.

If we build SAS and PTX code only for sm_X0 than we lose depending of the architecture up to 3%. This means if we create the SAS code for all architectures the user can increase the donate to 4%^^

I tested sm_21, sm_37 and sm_52
--- I am finished with my tests ---

from xmr-stak-nvidia.

Ok, just to make sure I read that correctly:

--generate-code arch=compute_20,code=sm_20 --generate-code arch=compute_20,code=sm_21 --generate-code arch=compute_30,code=sm_30 --generate-code arch=compute_35,code=sm_35 --generate-code arch=compute_37,code=sm_37 --generate-code arch=compute_50,code=sm_50 --generate-code arch=compute_52,code=sm_52 --generate-code arch=compute_60,code=sm_60 --generate-code arch=compute_61,code=sm_61 --generate-code arch=compute_62,code=sm_62

from xmr-stak-nvidia.

@fireice-uk Yes this is correct. This are all currently available architectures.

from xmr-stak-nvidia.

hi all, thanks for a great miner, it makes life a lot easier and i gladly pay the 1% with a smile. the CPU miner is working well, but i am getting this same error on the Nvidia card. any further ideas

from xmr-stak-nvidia.

@gary450 we need to build new windows binaries. We will announce the new binaries as soon as they are released.

from xmr-stak-nvidia.

from xmr-stak-nvidia.

@gary450 If you are building from source just add the flags above, alternatively I should have the time to do a new build tonight.

from xmr-stak-nvidia.

Just an update, I uploaded an extended build yesterday. This should resolve your issues. If you have any more problems, please open another issue.

from xmr-stak-nvidia.