My brain hurts trying to integrate CudeMiner into nVMiner  Maybe one of you guys that know CUDA much better then I can explain this to me: 1) CudaMiner is setup to use: compute_10,sm_10 (CUDA code generation) out of the ZipFile This compiles fine 2) I can change Code generation to: compute_30,sm_30;compute_35,sm_35 This too compiles fine in CudaMiner 3) I use said code in nvMiner with: compute_30,sm_30;compute_35,sm_35 and get this: Error 15 error : Instruction 'shf.l' requires .target sm_35 or higher C:\CCMiner\nvminer\ptxas Debug\nv_kernel2.compute_30.ptx, line 4555; nvminer Anyone know why? I haven't dug into it yet but was hoping somebody with experience in CUDA could give me a hint where to look or what to do! If I change Code generation in nvMiner to : compute_35,sm_35 I can compile/link (great first start) into an EXE that will immediately crash due to the following. Seems that between the different program versions we have three different versions of device_config: int device_config[8][2]; char *device_config[8]; int *device_config[8]; These are not compatible of course. Taking a break for a few before resolving this and moving on to the next issue that will pop up. Just wanted to post some progress and see if anyone could maybe tell me why I'm seeing the problem described with shf.l and maybe what to do about it? Sounds a bit like you dropped a #if __CUDA_ARCH__ >= 350 or #if __CUDA_ARCH__ < 350 somewhere along the way. Shf.l is funnelshift and is available only from 3.5 up, apparently you're ending up compiling it unconditionally regardless of arch and the compiler gives you the finger. |
|
|
|
Aaand I'm back. Had to focus a bit on shit I've been neglecting lately, including but not limited to my actual job and sleep  Say bye to (most of) the lag on Windows if you're willing to take a slight hit in performance. Basically I'm now splitting the heaviest part of the Cryptonight core into smaller batches with a little sleep between launching the batches. The default is still no splitting and no sleeping on Linux, on Windows it gets split into 64 batches with 100 microseconds sleep between the batches. Both values can be set on the command line per-device. I'm running it as I type this and while there is still noticeable lag, it's not too bad. The performance hit is pretty negligible on the defaults, something like 5 H/s. Well, on my system anyway. Latest win32 binary at https://github.com/tsiv/ccminer-cryptonight/releases/tag/v0.14 and source at https://github.com/tsiv/ccminer-cryptonight as you might expect. this commit broke mining under linux giving lot of: GPU #0: result for nonce $00000069 does not validate on CPU! reversing the commit and building again fixed it. Make sure to do a clean build, I had a lot of that when I was just rebuilding parts while working on it. Just did a clean build and confirmed it works. |
|
|
|
... I might be wrong on this but 2 GB should be enough for 8x96. I can do 8x120 on my Linux rig with a 2 GB 750 Ti:
...both works with kopiemtu too. 8x60 & 8x120 have nearly the same performance. 8x96 is a lot worse. what give you the most performance on your linux rig? thanks for the update. I'm running on 8x60, haven't found anything that works better. And like you said, 8x120 is practically the same, but just a little bit slower. |
|
|
|
And a crosspost from the CudaMiner/ccMiner thread: Aaand I'm back. Had to focus a bit on shit I've been neglecting lately, including but not limited to my actual job and sleep Say bye to (most of) the lag on Windows if you're willing to take a slight hit in performance. Basically I'm now splitting the heaviest part of the Cryptonight core into smaller batches with a little sleep between launching the batches. The default is still no splitting and no sleeping on Linux, on Windows it gets split into 64 batches with 100 microseconds sleep between the batches. Both values can be set on the command line per-device. I'm running it as I type this and while there is still noticeable lag, it's not too bad. The performance hit is pretty negligible on the defaults, something like 5 H/s. Well, on my system anyway. Latest win32 binary at https://github.com/tsiv/ccminer-cryptonight/releases/tag/v0.14 and source at https://github.com/tsiv/ccminer-cryptonight as you might expect. |
|
|
|
I promised a bounty for the Nvidia miner even though all my Nvidia cards are in the cupboard Post a BTC donation address tsiv so I can send my share (0.2BTC as listed) Any chance somebody tried the Gtx580 or Gtx680 I have 2 of each which I might slap on a system if worthwhile Tsiv donations and updates Sent my promised 0.2BTC now (0.20133330 to be exact) Thaaank you, sir, received and much appreciated. |
|
|
|
Is there a pre-existing XMR bounty wallet for the ATI miner?
If not, perhaps HardwarePal could make one, publish the view key? I don't want to hold it, just send to it.
I think smooth was collecting, but if HardwarePal is hiring someone directly then that would probably be okay, so long as the view key is published. Maybe we should check with smooth to see if he's collected anything? It doesn't seem like anyones working on this bounty besides HardwarePal, so my part of the ATI bounty still stands to be claimed by what's being worked on (150 XMR - Keyboard-Mash), and it looks like Tsiv will be claiming the Nvidia miner bounty. Tsiv can you please provide an XMR address and viewkey here? I have a an XMR address up on the Github project page, no viewkey though. If you need one I guess I can always create a new wallet for it, seeing as I can't figure out how to get the viewkey for an existing wallet. Apparently it is only shown once on wallet creation and if you ignored it (I did, didn't even know such a thing existed) you're out of luck? Another curve ball by the XMR wallet, they just keep coming |
|
|
|
Not gonna lie, working on this algo is making a huge dent on the whiskey fund. Cheers mate Here's 0.5 BTC in hope the excessive Whiskey supply will keep you short of our own performance benchmark  Transaction-ID 7fdaf9602034832a8045887c7b592b62d53b74377ddbf3d958129b9ad8d4ed55-000 seriously, great work on your ccminer forks. Keep it up! Christian Wow, didn't see that coming. It's not every day you take a man's work, more or less turn it against him and then get paid by him. Always wondered how much I was stepping on your toes with my release, guess that answers that question. Thank you, good sir, thank you very much Anyone played around with the launch config stuff for the TSIV version? I'm finding that 4x80 is far from optimal on certain systems. 6x60 gave me about a 25% boost on a GTX 770 and GTX 780, which on a GTX 860M 4x40 basically tripled my performance (from 50 H/s to 170 H/s). It would be great to hear what others are seeing with the -l parameter.
someone needs to come up with an autotune. Just sayin'... NOTE: separate autotuning would be required for the 3 kernels of the algorithm. Thought of that on the side, might be doable but some configs do so badly it might be TDR city all over again. I've managed values that give like 30 H/s compared to the inexplicably optimal ones that give around 280 H/s. Should probably take a poke at it anyway, at some point. Tried to paid for a few beer and longdrinks in bitcoins tonight. Didn't work because the stupid Windows Phone wallet software confused decimal dot and comma in the German version of Windows phone. After 2 embarassing attempts that ended in a failure message, I shelled out 30 Euros in cash.
Oh well... the sad sad state of Windows Phone. Of course switching the entire phone over to US English localization would have worked.
The slight relief of seeing I'm not the only one getting fsck'd by Microsoft software, priceless anyone actually compare CUDA 5.5 to CUDA 6.0 compiles? see if there really is a speed difference?
I actually compiled ccminer using 6.0 for quite some time, until I finally got fed up with editing the VC project files every time a new version came out. Nothing gained and nothing lost on going 5.5 -> 6.0 as far as I could tell. Obviosly this setting is too much for the 2gb ram of ti 750. But the new miner works fine with the old settings 40 blocks 8 treads.
Should be fine in theory, but if I'm not mistaken cudaMalloc requires a contiguous chunk of memory or it fails. So if there is even a tiniest allocation somewhere in the middle, the big allocation fails if there isn't a contiguous chunk of around 1.5 GB on either side of the smaller allocation. I might be wrong on this but 2 GB should be enough for 8x96. I can do 8x120 on my Linux rig with a 2 GB 750 Ti: FB Memory Usage
Total : 2047 MiB
Used : 1970 MiB
Free : 77 MiB
|
|
|
|
Aaand I'm back. Had to focus a bit on shit I've been neglecting lately, including but not limited to my actual job and sleep Say bye to (most of) the lag on Windows if you're willing to take a slight hit in performance. Basically I'm now splitting the heaviest part of the Cryptonight core into smaller batches with a little sleep between launching the batches. The default is still no splitting and no sleeping on Linux, on Windows it gets split into 64 batches with 100 microseconds sleep between the batches. Both values can be set on the command line per-device. I'm running it as I type this and while there is still noticeable lag, it's not too bad. The performance hit is pretty negligible on the defaults, something like 5 H/s. Well, on my system anyway. Latest win32 binary at https://github.com/tsiv/ccminer-cryptonight/releases/tag/v0.14 and source at https://github.com/tsiv/ccminer-cryptonight as you might expect. |
|
|
|
Does the new cryptonight release of ccminer support anything other than the 750 Ti? I tried to get it running on my laptop with a GeForce GT 750M (don't laugh) which is compute 3.0 compatible, but I got a message in windows that the driver had crashed and recovered and ccminer reported outrageously high hashrates while never submitting anything successfully to the pool and my GPU meter showing basically zero activity. Do I need to do more than put the "-a cryptonight" flag in the batch file?
I get exactly the same problem with a 750 ti, on Windows 8.1, as described in detail here: https://bitcointalk.org/index.php?topic=656841.msg7600519#msg7600519Any help appreciated. Same problem using wins 8.1. Any optimized version for wins 8.1 ? Cross-post from the bounty thread: I'm trying to use the pre-compiled ccminer-cryptonight_20140630_r2 ccminer on Windows 8.1 with a GTX750ti and seem to be having some problems getting results. I am pointing the miner at minexmr as indicated on their website: http://minexmr.com/with a batch file as follows: C:\monero\ccminer-cryptonight_20140630_r2\ccminer.exe -t 1 -d gtx750ti -o stratum+tcp://pool.minexmr.com:7777 -u <address> -p x At launch, I get a series of results like: GPU #0: GeForce GTX 750 Ti, using 40 blocks of 8 threads Pool set diff to 15000 GPU #0: GeForce GTX 750 Ti, 93.81 H/s then a popup says display driver stopped responding and has recovered. After that I see results with crazy high numbers of hashes like this: GPU #0: GeForce GTX 750 Ti, 163611988.12 H/s interspersed with 'stratum detected new block' but no accepted results within a half hour check period. I also tried downloading the previous release, but switching to that one makes the cmd.exe pop up and vanish immediately on my system (Windows 8.1, Driver 337.88). The GTX750ti is not attached to a display output. Any help appreciated. Not sure what's going wrong. Pretty sure it's still a TDR issue, the biggest part of the cryptonight core get still run as a single launch and it just might take that 2 seconds and Windows with default TDR delay considers the GPU stuck and does a driver reset. https://bitcointalk.org/index.php?topic=656841.msg7529269#msg7529269 for a workaround. I plan on looking at splitting the work down, at quick glance it looks like it could be run piece by piece. Will probably hurt performance a bit, have to save and reload the encryption keys on every kernel launch and launches themselves have some overhead. My thought was to make it a cmd line option, allowing the user to decide how much (or if) they want to split it up. Maybe add a few microseconds of sleep between the launches, stop the display freezing for 1+ seconds at a time and make the computer at least semi-usable. |
|
|
|
time to show some gratitude, the binary release readme.txt contains tsiv's "motivational addresses" pushed some VTC and XMR your way. Not gonna lie, working on this algo is making a huge dent on the whiskey fund. Cheers mate |
|
|
|
I'm trying to use the pre-compiled ccminer-cryptonight_20140630_r2 ccminer on Windows 8.1 with a GTX750ti and seem to be having some problems getting results. I am pointing the miner at minexmr as indicated on their website: http://minexmr.com/with a batch file as follows: C:\monero\ccminer-cryptonight_20140630_r2\ccminer.exe -t 1 -d gtx750ti -o stratum+tcp://pool.minexmr.com:7777 -u <address> -p x At launch, I get a series of results like: GPU #0: GeForce GTX 750 Ti, using 40 blocks of 8 threads Pool set diff to 15000 GPU #0: GeForce GTX 750 Ti, 93.81 H/s then a popup says display driver stopped responding and has recovered. After that I see results with crazy high numbers of hashes like this: GPU #0: GeForce GTX 750 Ti, 163611988.12 H/s interspersed with 'stratum detected new block' but no accepted results within a half hour check period. I also tried downloading the previous release, but switching to that one makes the cmd.exe pop up and vanish immediately on my system (Windows 8.1, Driver 337.88). The GTX750ti is not attached to a display output. Any help appreciated. Not sure what's going wrong. Pretty sure it's still a TDR issue, the biggest part of the cryptonight core get still run as a single launch and it just might take that 2 seconds and Windows with default TDR delay considers the GPU stuck and does a driver reset. https://bitcointalk.org/index.php?topic=656841.msg7529269#msg7529269 for a workaround. I plan on looking at splitting the work down, at quick glance it looks like it could be run piece by piece. Will probably hurt performance a bit, have to save and reload the encryption keys on every kernel launch and launches themselves have some overhead. My thought was to make it a cmd line option, allowing the user to decide how much (or if) they want to split it up. Maybe add a few microseconds of sleep between the launches, stop the display freezing for 1+ seconds at a time and make the computer at least semi-usable. |
|
|
|
Took the easy gains first, around 18% boost on 750 Ti. Still trying to wrap my head around the hard part.
[2014-06-30 00:11:59] GPU #5: GeForce GTX 750 Ti, 286.07 H/s [2014-06-30 00:11:59] GPU #1: GeForce GTX 750 Ti, 286.72 H/s [2014-06-30 00:11:59] GPU #2: GeForce GTX 750 Ti, 285.23 H/s [2014-06-30 00:11:59] GPU #0: GeForce GTX 750 Ti, 284.80 H/s [2014-06-30 00:11:59] GPU #4: GeForce GTX 750 Ti, 284.69 H/s [2014-06-30 00:11:59] GPU #3: GeForce GTX 750 Ti, 284.42 H/s [2014-06-30 00:12:04] GPU #0: GeForce GTX 750 Ti, 274.37 H/s [2014-06-30 00:12:04] accepted: 4/4 (100.00%), 1701.50 H/s (yay!!!) ...more performance gain than I thought. really nice. thanks! missing your donation address as signature or on github What's the power usage per GPU with the new build? It seems GPU's are getting close to Xeons in efficiency. My 6x750 Ti rig is drawing 310 W from wall at 280 H/s per card. BTC H81 with a Celeron G1820. Somewhere slightly under 50 W per card + whatever the rest of the rig pulls. Edit: Put some addresses on the Github front page earlier today btw. My "member rank" on these forums allows for a massive 50 character signature, pretty much good for nothing. |
|
|
|
I promised a bounty for the Nvidia miner even though all my Nvidia cards are in the cupboard Post a BTC donation address tsiv so I can send my share (0.2BTC as listed) Any chance somebody tried the Gtx580 or Gtx680 I have 2 of each which I might slap on a system if worthwhile I added some donation addresses on the project readme on Github for wallets that I have atm, copy&paste: BTC: 1JHDKp59t1RhHFXsTw2UQpR3F9BBz3R3cs DRK: XrHp267JNTVdw5P3dsBpqYfgTpWnzoESPQ JPC: Jb9hFeBgakCXvM5u27rTZoYR9j13JGmuc2 VTC: VwYsZFPb6KMeWuP4voiS9H1kqxcU9kGbsw XMR: 42uasNqYPnSaG3TwRtTeVbQ4aRY3n9jY6VXX3mfgerWt4ohDQLVaBPv3cYGKDXasTUVuLvhxetcuS16 ynt85czQ48mbSrWX I'm offering the 150 xmr pledge by Keyboard-Mash in the OP.
Overall I'm very satisfied with the program, and would gladly release partial/full bounty .. pending a quick answer for why I had to edit the registry to get the program to operate. Equipoise I will send you a few xmr outside of the bounty, thanks a lot for providing it! I would like to hear some more from tsiv.
It is actually explained on the project's front page on Github, I believe The initial release had the entire algorithm stuffed into a single huge CUDA kernel. Having to do the whole slow algorithm in one go had a tendency to take just a bit over 2 seconds per kernel launch, with 2 seconds being the timeout for Windows getting impatient and going "hmmh, I haven't heard from the GPU in 2 seconds. Must've crashed, better reset the driver." The registry tweak works around the problem by increasing the time that Windows allows the GPU to be "unresponsive" aka stuck running a CUDA kernel. This has been addressed in later releases, mainly by splitting the single huge kernel into smaller pieces and making parts of the hash faster. The slowest part is still quite slow, taking roughly 1.4 seconds with launch config 8x60 on a 750 Ti but it should stay well within the default 2 second window. There is something more to be done about the -l MxN.
About the first number M:
"First of all, your thread block size should always be a multiple of 32, because kernels issue instructions in warps (32 threads). For example, if you have a block size of 50 threads, the GPU will still issue commands to 64 threads and you'd just be wasting them."
About the second number N:
You could find it by gradually increasing it until your card stop working (showing impossible hash rate 3474958.52 H/s) and then restart is needed for maximum performance (but not for testing), because without restart my hash rate is felling 2x compared to the same options before the crash.
The "magical numbers" for 650M seems to be -l 128x5
I realize the 8x60 or 8x40 make absolutely no sense, they're something I ran into while trying out different values. The reasonable values would be based on the number of SMM/SMX on the GPU and 32 or 64 threads per block would make a lot of sense. I can't tell exactly why performance takes a dive if you try 64x5 for example, it should be a very good value to start at. Might have something to do with the huge amount of random global memory access in the second major loop of the algo, trying to do more work in parallel bottlenecks at the memory access? Good news is that I've since modified 2 of the 3 main loops to use 8 parallel threads per hash as opposed to the original 1 thread per hash. So essentially 8x60 leads to running 64 threads per block for those two loops. Still working on the last loops, it does seem a fair bit harder to make it more parallel. |
|
|
|
|
Well, that took longer than I wanted. Finally finished restructuring the hash into smaller, sequentially launched kernels. Mainly a preparatory step for throwing in more threads per hash for certain parts of the algorithm, but it might alleviate the TDR problems a little.
Spent probably one evening on the actual work, next two debugging because I forgot to copy the keccak tables into device memory in the new split core/extra init...
|
|
|
|
wonder if the same trick could be applied ...get it on djm are those code lines all the trick to get cryptonight working on a gpu? He's conveniently ignoring the three massive for-loops that run 131072, 262144 and 131072 iterations of AES-encryption each  The final SINGLE keccak and SINGLE jh/groestl/blake/skein are literally nothing compared to the shit that comes before them |
|
|
|
Minor update + Win binary: https://github.com/tsiv/ccminer-cryptonight/releasesNo longer wasting CPU cycles on busy waiting, some checks on the initial memory allocations before getting to work and per device launch settings. Seems like we have a lot of Win 8 users with problems, but apparently it works for some. It is a mystery, my money is still on hitting TDR. If that's the case http://support.microsoft.com/kb/2665946 will provide a workaround. It's not pretty but increasing the timeout from the default 2 seconds to something like 5 seconds shouldn't hurt anyone. The real fix would be breaking up the kernel into smaller pieces that are run in sequence as opposed to one huge kernel that does the whole hash in one go and takes near forever (well, over 2 seconds) to do it. Looking into that, should be relatively easy. A compute 2.0/2.1 version shouldn't be too hard either but I'm not sure if they're going to perform too well and worse than bad is... very bad? |
|
|
|
|
Show Posts
