Topic: CCminer(SP-MOD) Modded NVIDIA Maxwell / Pascal kernels. - page 1178. (Read 2347597 times)
My 4card testrig(2x 750ti, 1x980, 1x970) is up 1MHASH with my new spreadcoin miner(standard clocks). The 750ti cards are not doing so well. Most improvements on 970 and 980 cards.
it is the compiler who is a bit confused about the asm command, because t2 initialized or not gets overwritten...
Actually I would be curious to know why the 2 lines asm has been replaced by 2 asm statement...
Same number of registers are allocated...
Actually I would be curious to know why the 2 lines asm has been replaced by 2 asm statement...
Same number of registers are allocated...
I have removed the warning, and everything should compile.
the latest git compiles and runs well ... tanx sp ...
admittedly - i have only tested with x11 for now ... but will get quark running in the next few days after i finish a few of the rebuilds ...
#crysx
it is the compiler who is a bit confused about the asm command, because t2 initialized or not gets overwritten...
Actually I would be curious to know why the 2 lines asm has been replaced by 2 asm statement...
Same number of registers are allocated...
Actually I would be curious to know why the 2 lines asm has been replaced by 2 asm statement...
Same number of registers are allocated...
I have removed the warning, and everything should compile.
SP_ v32 WILL NOT BUILD ON LINUX--
I tried building it and got dozens of ""t2" set but not used" errors. I have no executable left on exit.
I checked "ccminer.cpp" for the correction that flipclip mentioned earlier. The correction is in place in the git-code.
I am curently running tpruvot's 1.5.2-git release, it has been very stable. A loss of 5mh/s for the rig, compared to sp_'s best, is painfully evident. --scryptr
I tried building it and got dozens of ""t2" set but not used" errors. I have no executable left on exit.
I checked "ccminer.cpp" for the correction that flipclip mentioned earlier. The correction is in place in the git-code.
I am curently running tpruvot's 1.5.2-git release, it has been very stable. A loss of 5mh/s for the rig, compared to sp_'s best, is painfully evident. --scryptr
latest git pull sphash not build on linux:
./cuda_helper.h(73): Error: Cannot store to pointer that points to constant memory space
make[2]: *** [x15/cuda_x15_whirlpool.o] Error 1
make[2]: *** Waiting for unfinished jobs....
./cuda_helper.h(73): Error: Cannot store to pointer that points to constant memory space
make[2]: *** [x15/cuda_x15_whirlpool.o] Error 1
make[2]: *** Waiting for unfinished jobs....
This is a different fix then before. Unfortunately this is getting out of my realm here but when I made the below fixes, it compiled (Ubuntu 14.04) and quark ran fine (not sure about x15):
In Cudahelper.h (line 68):
FROM:
__device__ __forceinline__ uint64_t REPLACE_HIWORD(const uint64_t &x, const uint32_t y)
TO:
__device__ __forceinline__ uint64_t REPLACE_HIWORD(const uint64_t x, const uint32_t y)
(line 78):
FROM:
__device__ __forceinline__ uint64_t REPLACE_LOWORD(const uint64_t &x, const uint32_t y)
TO:
__device__ __forceinline__ uint64_t REPLACE_LOWORD(const uint64_t x, const uint32_t y)
Compiled and seems to be running fine.
cuda_helper.h ERRORS --
On lines 68, 78 (mentioned in your post) and lines 70, 80, and 84, there appear to be errors/typos. I am not familiar enough with the code to fix it, but the "t2"variable is there, and it kicks up dozens of warnings at compilation time. I have been able to compile the code with your fix, but the "t2" variable still produces warnings by the dozen. --scryptr
(in the first line 68, not sure t2=0 makes sense.)
DJM34--
I didn't think so, either! In fact, I deleted "=0" and compiled again. It compiled, as before, with dozens of ""t2" set but not used" errors. In my first post, I used the word "defined", instead of "set", but these are continual warnings during compilation. --scryptr
Actually I would be curious to know why the 2 lines asm has been replaced by 2 asm statement...
Same number of registers are allocated...
By email.
I added another fix, you might need. @ github.
later today I wil release the first version of the spreadminer to the ppl who have donated 0.1 BTC. The miner is not
finished, but it works, and a little faster than the old one.
later today I wil release the first version of the spreadminer to the ppl who have donated 0.1 BTC. The miner is not
finished, but it works, and a little faster than the old one.
tanx sp ...
downloading the git pull now ...
how will you distribute the spreadx11 miner to the donors? ...
id like to donate some more also - which algo would you prefer to have this time round?
#crysx
I added another fix, you might need. @ github.
later today I wil release the first version of the spreadminer to the ppl who have donated 0.1 BTC. The miner is not
finished, but it works, and a little faster than the old one.
later today I wil release the first version of the spreadminer to the ppl who have donated 0.1 BTC. The miner is not
finished, but it works, and a little faster than the old one.
I have fixed the build now.
pull - compile - test ... doing that now mate ...
#crysx
I have fixed the build now.
SP_ v32 WILL NOT BUILD ON LINUX--
I tried building it and got dozens of ""t2" set but not used" errors. I have no executable left on exit.
I checked "ccminer.cpp" for the correction that flipclip mentioned earlier. The correction is in place in the git-code.
I am curently running tpruvot's 1.5.2-git release, it has been very stable. A loss of 5mh/s for the rig, compared to sp_'s best, is painfully evident. --scryptr
I tried building it and got dozens of ""t2" set but not used" errors. I have no executable left on exit.
I checked "ccminer.cpp" for the correction that flipclip mentioned earlier. The correction is in place in the git-code.
I am curently running tpruvot's 1.5.2-git release, it has been very stable. A loss of 5mh/s for the rig, compared to sp_'s best, is painfully evident. --scryptr
latest git pull sphash not build on linux:
./cuda_helper.h(73): Error: Cannot store to pointer that points to constant memory space
make[2]: *** [x15/cuda_x15_whirlpool.o] Error 1
make[2]: *** Waiting for unfinished jobs....
./cuda_helper.h(73): Error: Cannot store to pointer that points to constant memory space
make[2]: *** [x15/cuda_x15_whirlpool.o] Error 1
make[2]: *** Waiting for unfinished jobs....
This is a different fix then before. Unfortunately this is getting out of my realm here but when I made the below fixes, it compiled (Ubuntu 14.04) and quark ran fine (not sure about x15):
In Cudahelper.h (line 68):
FROM:
__device__ __forceinline__ uint64_t REPLACE_HIWORD(const uint64_t &x, const uint32_t y)
TO:
__device__ __forceinline__ uint64_t REPLACE_HIWORD(const uint64_t x, const uint32_t y)
(line 78):
FROM:
__device__ __forceinline__ uint64_t REPLACE_LOWORD(const uint64_t &x, const uint32_t y)
TO:
__device__ __forceinline__ uint64_t REPLACE_LOWORD(const uint64_t x, const uint32_t y)
Compiled and seems to be running fine.
cuda_helper.h ERRORS --
On lines 68, 78 (mentioned in your post) and lines 70, 80, and 84, there appear to be errors/typos. I am not familiar enough with the code to fix it, but the "t2"variable is there, and it kicks up dozens of warnings at compilation time. I have been able to compile the code with your fix, but the "t2" variable still produces warnings by the dozen. --scryptr
(in the first line 68, not sure t2=0 makes sense.)
DJM34--
I didn't think so, either! In fact, I deleted "=0" and compiled again. It compiled, as before, with dozens of ""t2" set but not used" errors. In my first post, I used the word "defined", instead of "set", but these are continual warnings during compilation. --scryptr
same here ... continual t2 warnings and a error at the end ... so no compile ...
t2 ... does that mean terminator 2 is coming back for revenge - and thats why its not working?
ok ok - so im not funny ... bite me ...
#crysx
SP_ v32 WILL NOT BUILD ON LINUX--
I tried building it and got dozens of ""t2" set but not used" errors. I have no executable left on exit.
I checked "ccminer.cpp" for the correction that flipclip mentioned earlier. The correction is in place in the git-code.
I am curently running tpruvot's 1.5.2-git release, it has been very stable. A loss of 5mh/s for the rig, compared to sp_'s best, is painfully evident. --scryptr
I tried building it and got dozens of ""t2" set but not used" errors. I have no executable left on exit.
I checked "ccminer.cpp" for the correction that flipclip mentioned earlier. The correction is in place in the git-code.
I am curently running tpruvot's 1.5.2-git release, it has been very stable. A loss of 5mh/s for the rig, compared to sp_'s best, is painfully evident. --scryptr
latest git pull sphash not build on linux:
./cuda_helper.h(73): Error: Cannot store to pointer that points to constant memory space
make[2]: *** [x15/cuda_x15_whirlpool.o] Error 1
make[2]: *** Waiting for unfinished jobs....
./cuda_helper.h(73): Error: Cannot store to pointer that points to constant memory space
make[2]: *** [x15/cuda_x15_whirlpool.o] Error 1
make[2]: *** Waiting for unfinished jobs....
This is a different fix then before. Unfortunately this is getting out of my realm here but when I made the below fixes, it compiled (Ubuntu 14.04) and quark ran fine (not sure about x15):
In Cudahelper.h (line 68):
FROM:
__device__ __forceinline__ uint64_t REPLACE_HIWORD(const uint64_t &x, const uint32_t y)
TO:
__device__ __forceinline__ uint64_t REPLACE_HIWORD(const uint64_t x, const uint32_t y)
(line 78):
FROM:
__device__ __forceinline__ uint64_t REPLACE_LOWORD(const uint64_t &x, const uint32_t y)
TO:
__device__ __forceinline__ uint64_t REPLACE_LOWORD(const uint64_t x, const uint32_t y)
Compiled and seems to be running fine.
cuda_helper.h ERRORS --
On lines 68, 78 (mentioned in your post) and lines 70, 80, and 84, there appear to be errors/typos. I am not familiar enough with the code to fix it, but the "t2"variable is there, and it kicks up dozens of warnings at compilation time. I have been able to compile the code with your fix, but the "t2" variable still produces warnings by the dozen. --scryptr
(in the first line 68, not sure t2=0 makes sense.)
DJM34--
I didn't think so, either! In fact, I deleted "=0" and compiled again. It compiled, as before, with dozens of ""t2" set but not used" errors. In my first post, I used the word "defined", instead of "set", but these are continual warnings during compilation. --scryptr
SP_ v32 WILL NOT BUILD ON LINUX--
I tried building it and got dozens of ""t2" set but not used" errors. I have no executable left on exit.
I checked "ccminer.cpp" for the correction that flipclip mentioned earlier. The correction is in place in the git-code.
I am curently running tpruvot's 1.5.2-git release, it has been very stable. A loss of 5mh/s for the rig, compared to sp_'s best, is painfully evident. --scryptr
I tried building it and got dozens of ""t2" set but not used" errors. I have no executable left on exit.
I checked "ccminer.cpp" for the correction that flipclip mentioned earlier. The correction is in place in the git-code.
I am curently running tpruvot's 1.5.2-git release, it has been very stable. A loss of 5mh/s for the rig, compared to sp_'s best, is painfully evident. --scryptr
latest git pull sphash not build on linux:
./cuda_helper.h(73): Error: Cannot store to pointer that points to constant memory space
make[2]: *** [x15/cuda_x15_whirlpool.o] Error 1
make[2]: *** Waiting for unfinished jobs....
./cuda_helper.h(73): Error: Cannot store to pointer that points to constant memory space
make[2]: *** [x15/cuda_x15_whirlpool.o] Error 1
make[2]: *** Waiting for unfinished jobs....
This is a different fix then before. Unfortunately this is getting out of my realm here but when I made the below fixes, it compiled (Ubuntu 14.04) and quark ran fine (not sure about x15):
In Cudahelper.h (line 68):
FROM:
__device__ __forceinline__ uint64_t REPLACE_HIWORD(const uint64_t &x, const uint32_t y)
TO:
__device__ __forceinline__ uint64_t REPLACE_HIWORD(const uint64_t x, const uint32_t y)
(line 78):
FROM:
__device__ __forceinline__ uint64_t REPLACE_LOWORD(const uint64_t &x, const uint32_t y)
TO:
__device__ __forceinline__ uint64_t REPLACE_LOWORD(const uint64_t x, const uint32_t y)
Compiled and seems to be running fine.
cuda_helper.h ERRORS --
On lines 68, 78 (mentioned in your post) and lines 70, 80, and 84, there appear to be errors/typos. I am not familiar enough with the code to fix it, but the "t2"variable is there, and it kicks up dozens of warnings at compilation time. I have been able to compile the code with your fix, but the "t2" variable still produces warnings by the dozen. --scryptr
(in the first line 68, not sure t2=0 makes sense.)
SP_ v32 WILL NOT BUILD ON LINUX--
I tried building it and got dozens of ""t2" set but not used" errors. I have no executable left on exit.
I checked "ccminer.cpp" for the correction that flipclip mentioned earlier. The correction is in place in the git-code.
I am curently running tpruvot's 1.5.2-git release, it has been very stable. A loss of 5mh/s for the rig, compared to sp_'s best, is painfully evident. --scryptr
I tried building it and got dozens of ""t2" set but not used" errors. I have no executable left on exit.
I checked "ccminer.cpp" for the correction that flipclip mentioned earlier. The correction is in place in the git-code.
I am curently running tpruvot's 1.5.2-git release, it has been very stable. A loss of 5mh/s for the rig, compared to sp_'s best, is painfully evident. --scryptr
latest git pull sphash not build on linux:
./cuda_helper.h(73): Error: Cannot store to pointer that points to constant memory space
make[2]: *** [x15/cuda_x15_whirlpool.o] Error 1
make[2]: *** Waiting for unfinished jobs....
./cuda_helper.h(73): Error: Cannot store to pointer that points to constant memory space
make[2]: *** [x15/cuda_x15_whirlpool.o] Error 1
make[2]: *** Waiting for unfinished jobs....
This is a different fix then before. Unfortunately this is getting out of my realm here but when I made the below fixes, it compiled (Ubuntu 14.04) and quark ran fine (not sure about x15):
In Cudahelper.h (line 68):
FROM:
__device__ __forceinline__ uint64_t REPLACE_HIWORD(const uint64_t &x, const uint32_t y)
TO:
__device__ __forceinline__ uint64_t REPLACE_HIWORD(const uint64_t x, const uint32_t y)
(line 78):
FROM:
__device__ __forceinline__ uint64_t REPLACE_LOWORD(const uint64_t &x, const uint32_t y)
TO:
__device__ __forceinline__ uint64_t REPLACE_LOWORD(const uint64_t x, const uint32_t y)
Compiled and seems to be running fine.
cuda_helper.h ERRORS --
On lines 68, 78 (mentioned in your post) and lines 70, 80, and 84, there appear to be errors/typos. I am not familiar enough with the code to fix it, but the "t2"variable is there, and it kicks up dozens of warnings at compilation time. I have been able to compile the code with your fix, but the "t2" variable still produces warnings by the dozen. --scryptr
I'm wondering what's the difference between intensity and throughput. Spreadminer has throughput (-x) and ccminer has intensity (-i) parameters but I can never go above -i 20 and not because of running out of memory, it's just simply crashes (eg. -i 20 = ~25% VRAM usage and -i 21 = crash). On the other hand I can play around with throughput which lets me use almost all VRAM even though that's not the fastest.
For example, a 780 Ti does around 2.6mh/s with spreadminer by default while using 788 MB VRAM but with a throughput of 30 it does around 3.15 mh/s and uses 2463 MB VRAM. Anyway, I wouldn't mind playing with more parameters if there is a possibility of gains.
the throughput is the total number of gpu thread used by the algorithm, the intensity lead to that number but is packed differently (don't remember how... power of 2 or something like that For example, a 780 Ti does around 2.6mh/s with spreadminer by default while using 788 MB VRAM but with a throughput of 30 it does around 3.15 mh/s and uses 2463 MB VRAM. Anyway, I wouldn't mind playing with more parameters if there is a possibility of gains.
SP_ v32 WILL NOT BUILD ON LINUX--
I tried building it and got dozens of ""t2" defined but not used" errors. I have no executable left on exit.
I checked "ccminer.cpp" for the correction that flipclip mentioned earlier. The correction is in place in the git-code.
I am curently running tpruvot's 1.5.2-git release, it has been very stable. A loss of 5mh/s for the rig, compared to sp_'s best, is painfully evident. --scryptr
I tried building it and got dozens of ""t2" defined but not used" errors. I have no executable left on exit.
I checked "ccminer.cpp" for the correction that flipclip mentioned earlier. The correction is in place in the git-code.
I am curently running tpruvot's 1.5.2-git release, it has been very stable. A loss of 5mh/s for the rig, compared to sp_'s best, is painfully evident. --scryptr
latest git pull sphash not build on linux:
./cuda_helper.h(73): Error: Cannot store to pointer that points to constant memory space
make[2]: *** [x15/cuda_x15_whirlpool.o] Error 1
make[2]: *** Waiting for unfinished jobs....
./cuda_helper.h(73): Error: Cannot store to pointer that points to constant memory space
make[2]: *** [x15/cuda_x15_whirlpool.o] Error 1
make[2]: *** Waiting for unfinished jobs....
This is a different fix then before. Unfortunately this is getting out of my realm here but when I made the below fixes, it compiled (Ubuntu 14.04) and quark ran fine (not sure about x15):
In Cudahelper.h (line 68):
FROM:
__device__ __forceinline__ uint64_t REPLACE_HIWORD(const uint64_t &x, const uint32_t y)
TO:
__device__ __forceinline__ uint64_t REPLACE_HIWORD(const uint64_t x, const uint32_t y)
(line 78):
FROM:
__device__ __forceinline__ uint64_t REPLACE_LOWORD(const uint64_t &x, const uint32_t y)
TO:
__device__ __forceinline__ uint64_t REPLACE_LOWORD(const uint64_t x, const uint32_t y)
Compiled and seems to be running fine.
I'm wondering what's the difference between intensity and throughput. Spreadminer has throughput (-x) and ccminer has intensity (-i) parameters but I can never go above -i 20 and not because of running out of memory, it's just simply crashes (eg. -i 20 = ~25% VRAM usage and -i 21 = crash). On the other hand I can play around with throughput which lets me use almost all VRAM even though that's not the fastest.
For example, a 780 Ti does around 2.6mh/s with spreadminer by default while using 788 MB VRAM but with a throughput of 30 it does around 3.15 mh/s and uses 2463 MB VRAM. Anyway, I wouldn't mind playing with more parameters if there is a possibility of gains.
For example, a 780 Ti does around 2.6mh/s with spreadminer by default while using 788 MB VRAM but with a throughput of 30 it does around 3.15 mh/s and uses 2463 MB VRAM. Anyway, I wouldn't mind playing with more parameters if there is a possibility of gains.
SP_ v32 WILL NOT BUILD ON LINUX--
I tried building it and got dozens of ""t2" defined but not used" errors. I have no executable left on exit.
I checked "ccminer.cpp" for the correction that flipclip mentioned earlier. The correction is in place in the git-code.
I am curently running tpruvot's 1.5.2-git release, it has been very stable. A loss of 5mh/s for the rig, compared to sp_'s best, is painfully evident. --scryptr
I tried building it and got dozens of ""t2" defined but not used" errors. I have no executable left on exit.
I checked "ccminer.cpp" for the correction that flipclip mentioned earlier. The correction is in place in the git-code.
I am curently running tpruvot's 1.5.2-git release, it has been very stable. A loss of 5mh/s for the rig, compared to sp_'s best, is painfully evident. --scryptr
latest git pull sphash not build on linux:
./cuda_helper.h(73): Error: Cannot store to pointer that points to constant memory space
make[2]: *** [x15/cuda_x15_whirlpool.o] Error 1
make[2]: *** Waiting for unfinished jobs....
./cuda_helper.h(73): Error: Cannot store to pointer that points to constant memory space
make[2]: *** [x15/cuda_x15_whirlpool.o] Error 1
make[2]: *** Waiting for unfinished jobs....
I run miners on realtime since ever and only cudaminer locked up the system a few times when it crashed a card. I very rarely had that with ccminer.
Yeah, but it's still possible
That's why we really need --cpu-priority and --cpu-affinity to robustly set them up through cli & scripts. There are already workarounds for this, but built-in is always better, easier and more straight-forward.
I run miners on realtime since ever and only cudaminer locked up the system a few times when it crashed a card. I very rarely had that with ccminer.
I'm gonna keep repeating it: setting to high, higher than high, stoned high, doesn't make a difference. Setting it to realtime does, but might lock up your system.
that's rightYep
Unless you assign it to a specific core (if you have more than one on your rig ), so you still have cores left that won't be locked.Chances of locking up are low though, but it is possible. One would want to eliminate as much point-of-failures on a continuous mining system.
Jump to: