Topic: [ANN] sgminer v5 - optimized X11/X13/NeoScrypt/Lyra2RE/etc. kernel-switch miner - page 88. (Read 877859 times)

So wolf0 isn't the only one with a kernel mod that works better on the 290's than anything else..

Just ran a couple of quick tests, the first on SGMiner 5, right from Github. The source I used was a bit old, because I forgot to pull before I did the test, so for reference, I used commit f27f8dd544a107523435363e7b26bfc294719542, pushed on Tue Jan 13 11:00:57 2015 +0100. I highly doubt anything in Qubit has changed since then, however. Anyways, the rig I tested on, Freya, currently has a 270X, 280X, 290X, and 7950. The cards are OC'd - card types, clocks, and memory types are in the notepad.

Screenshot of stock SG5 on qubit (NSFW): https://ottrbutt.com/miner/qubitstock-03162015.png

I also spent maybe 2 - 3 hours or less on Qubit a while ago one afternoon. As such, the results are approaching barely acceptable in my opinion, but I did it just for the hell of it. Maybe I'll finish up with all the more obvious hashrate increases to be had at some point, then clean and polish the code, but not now. Nevertheless, here it is:

Screenshot of modified SG5 with completely rewritten qubit kernel (NSFW): https://ottrbutt.com/miner/qubitwolf-03162015.png

So Wolf's post just confined that the stock code for cubit support is hideously inefficient!

I had suspected this since mining it in the last 2 days as my fans spin down considerably when mining Qubit compared to x11(with wolfs bins).


So wolf was your optimisation of qubit as case of unhobbling a deliberately inefficient code base?

not trying to go too conspiratorial but it would not be the first time we have seen deliberate sabotage of publicly available GPU miners.

Meh, not so interesting after all. If you're not specifying --gpu-platform, then add --gpu-platform 1. If that don't work, try --gpu-platform 2. Almost certain to fix your shit.

Okay, I'm interested. Open a command prompt, go to the directory you have SGMiner in, and copy and paste the contents of your batch file into the shell. Add -T --debug, though; pastebin the output.

The reason for opening the terminal and doing this is to prevent the window from immediately closing upon SGMiner's exit. You could also add "pause" on a new line in your batch file, but don't forget the extra options.

Those cards must be screaming 
How much of a %age improvement did you get?

can any1 pls tell me why all newer version of sgminer crash instantly?

on one PC working fine, on other crash instantly when I opet .bat file

  

thanks

Okay, now we're cooking with gas. SGMiner doesn't just exit on no params, it prompts you - I forgot. Therefore, what is happening on PC 2 is likely a crash, as it is exiting abnormally.

Now the question becomes, what is the difference between PC 1 and PC 2? I'd put money on driver version and/or operating system.

What you're describing isn't even probably a crash, it's SGMiner exiting normally, most likely. You probably fucked up the options.

Also, OF COURSE double-clicking the exe will result in SGMiner closing! You expect it to get settings by reading your mind? 

sgminer 5.1.1-2-g8cb4 built from git works fine with x11 and x13 bins released by Wolf0

Here is a small neoscrypt kernel improvement for free, since I am mostly doing X11 anyway.
It gave me a 5.8% speedup on my reference R9 290 card (with Stilt bios),
from 290.2 to 307Kh/s  at 800/1500 core/mem freq on Ubuntu 12.04 with stock drivers.
I didnt try it on my R9 280x cards, so please post your results if you try this.

You will have to mod the kernel as per the code below.
The bottleneck in this kernel is the way it stores the 128 intermediate results of chacha and salsa in global memory.
By doing the change below you are reducing stalls/latency by not making read/writes to same/adjacent memory banks.

Change:
void ScratchpadStore(__global void *V, void *X, uchar idx)
{
   ((__global ulong16 *)V)[idx << 1] = ((ulong16 *)X)[0];
   ((__global ulong16 *)V)[(idx << 1) + 1] = ((ulong16 *)X)[1];
}

void ScratchpadMix(void *X, const __global void *V, uchar idx)
{
   ((ulong16 *)X)[0] ^= ((__global ulong16 *)V)[idx << 1];
   ((ulong16 *)X)[1] ^= ((__global ulong16 *)V)[(idx << 1) + 1];
}

To:
void ScratchpadStore(__global void *V, void *X, uchar idx)
{
   ((__global ulong16 *)V)[idx] = ((ulong16 *)X)[0];
   ((__global ulong16 *)V)[idx + 128] = ((ulong16 *)X)[1];
}
void ScratchpadMix(void *X, const __global void *V, uchar idx)
{
   ((ulong16 *)X)[0] ^= ((__global ulong16 *)V)[idx];
   ((ulong16 *)X)[1] ^= ((__global ulong16 *)V)[idx + 128];
}

Nah, your bins work just fine with latest sgminer.

I did this

Stop miner
rm /opt/ifmi/*.bin
Change the config file to set worksize=64
restart miner
Once it's running again, stop mining
rename wolf's bin file to the exact same name as the one in /opt/ifmi
Copy the renamed bin over the existing one
reboot

Now my miner will not work even after a reboot

Edit: Just installed pimp-1.6.0-amd-14.6

Stopped the miner from fresh install, selected x11-mod, edited to 64 intensity and added own pools, started and stopped miner.

/opt/ifmi/ is giving me 2 .bin one x11ETC and one darkcoinETC. I have replaced both bins and still no increase.

Any ideas where I am going wrong?.

ensure you are using "worksize" : "64", "keccak-unroll" : "0", "hamsi-expand-big" : "4".

Not just a bin, modded miner.