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

v5_0 has a massive amount of changes from the original...
also if you have onboard video on your MB it might be detecting it instead of your amd cards, this has been an issue in the past
usually you can get by it by specifying "gpu-platform" : "1", in the config or --gpu-platform 1 in command line (platform 0 being the onboard video)

thank you badman, i am exploring an idea, i see somehow intel openCL drivers got installed and when i doo sgminer -n it shows Inten Open CL 1.2  but on my other rig it correctly lists AMD OpenCL ...

so im blowing away the windows install and doing a fresh install and trying again... still weird why the older 4.x branch would still be able to identify my card but the 5.0 cant.

don't know of any reason support would be removed, but that info should be coming though the adl_sdk i think
you might open an issue at https://github.com/sgminer-dev/sgminer/issues?state=open
you will be more likely to get info on that from there
edit: if you built it from source be sure you added the ADL_SDK/*.h files to sgminer/ADL_SDK/ before you build

why is it when i do a sgminer -n with the latest build on the v5 branch my card is not recognised... but if i go back and use 4.1.271 it shows up perfectly fine ?

its a Pitcairn Gigabyte R9 270 GPU

is there any reason that Pircairn support would of been removed in the latest branch of sgminer ?

that worked! It seems that sg5 doesn't necessarily work well with all the settings I've used in the past with the older 4.0.1.

thank you!  

try to dial back you intensity till your hashrate starts to drop
sometimes if you set it too high you will get stale shares
also can be caused by latency to the pool server
if you are on a p2pool try to find one with the lowest latency

The key is the algos you listed... for all the rest like X11 and whatnot, TC does nothing to boost speed one way or another.... in fact I just leave that blank now or dont even put it in.

Not a BS at least for Win rigs. To reproduce - set large enough TC on a rig with a lot of GPUs, f.e. 6x290 with TC 32768 or 6x7950 with TC 40960/24000. On rigs with less than 8GB?(depends) of RAM some cards will report -4 kernel error. Stick some more ram - issue will go away. Imo that's only for scrypt/scryptn/scrypt-jane(and other memory intensive algos), cause for those algos higher TC means higher GPU RAM usage. Prly thats cause of DMA or maybe OCL or Win maps GPU RAM into system RAM or something like that..
But RAM does not affect performance, only lack of it prevents some GPUs starting up.

I saw huge performance boosts when moving to 14.6 on 64-bit Gentoo linux.  I am running the 3.15.0 kernel, with xorg-server 1.15.1, and ati-drivers 14.6_beta1.

RAM doesn't matter at all (at least on linux, can't say for sure with Windows).  I don't know who started that rumour, but it's bullshit.  I have run all of my rigs on 2GB of ram, and I've never seen any performance loss or inability to mine an algorithm as a result.

Hello, i have a little bit off topic questions. Sorry for it, but in this topic someone could actualy know whats going on
1) Is there a difference between amd64/i386 drivers? On Debian i386 i got this X11,13 boost with 14.6 drivers, but cant replicate it on 64bit Debian... On 32 bit PIMP,BAMT,SMOS the 14.6. driver is working also OK, i get the 3,6MHs (7950), 2,6MHs  (7870). On amd64 debian i got only 2,6MHs and 1,8Mhs - those numbers are exactly the same I got using driver 13.12. Same hashrate problem on sgminer_5 and djm34 miner - it is truly distro specific problem - I reinstalled debian64 many times, nothing i tryed helped - on debian32 i did exactly the same and i got 14.6. boost hashrate on first install.

I used exactly same "flow" for installation of 64/32bit debian, only difference is APP_SDK 64/32. Catalyst and ADL_SDK is for both arch, (using linux-amd-catalyst-14.6-beta-v1.0-may23) ... Im using this guide for installation of debian mining rig: https://bitsharestalk.org/index.php?topic=2980.0 (I had to remove all snd_* modules coz kernel error sometimes appeared)

2) Windows users can copy some 14.6 driver files into miners folder, and generated kernels (bin) and hashrate is like on 14.6. drivers even the older catalyst is installed. Is something like this possible on linux? (or I misunderstood and those driver dll files are needed for transfered bin files to work?)

Thank you very much for any hints, informations and sorry for my written english

P.S. im dwelling on 64b debian coz of RAM limitations on 32b systems... Does amount of RAM really matter? (could you spawn more gpu-threads with more RAM? currently using just 2 point something GB ram of total 2x2 RAM installed)

No. I'm now seeing 10-20% cpu usage where as before it was only 2-5%.

is it normal for my CPU temps to rise after few minutes while using sgminer x11 .
xeon 3520
1x7950
win 8.1

mine have been running almost 24 hours now with no sick so long as i dont go over 1040/1500 for my sapphire 290x (6.03mh/s) and 1075/1375 on my gigabyte 290's (5.31mh/s)

setting this to 1 on aggressive overclocks causes some hung rigs for me, and used to cause HW errors back in aznboy84's miner
bullus's bin just wrecks my drivers, I can't use it anymore it kills cards and have to reboot every 15 mins
testing once again with regular intensities; it does not like my xI's for long-term stability

only my Tri-X OC cards go sick, never my standard Sapphires... same clocks as the Tri-X OCs

looks like we need a "sph-luffa-parallel" : "1", option since this was set to 0 due to causing some cards to crash (i think this was the reason anyway...)
and maybe look at if the change in the groestl.cl file was necessary or desirable
i don't know enough about how all this works to do more than compare and copy/paste....

6M on x11 on xI:48 (2816x48=131568) as opposed to I:17=131072




6M across all cards on rawintensity: 140800 = [2816x5x10] which, I'm a dumbass, is the same as xI:50

Here's how to nick up to 18M on nist5

Take your shaders and multiply by 5

For me was 2816x5 = 14080, this is your base thread concurrency if you specify an algo that doesn't exist, and it builds ckolivas with that TC

Next multiply this value by the total number of threads you are passing through your entire rig.

For me was 3 cards X 2 gpu-threads = 6 x 14080 = 84480 = xI: 30 as opposed to I:16=65536




Works better on a 3 card rig with xI: 30 as it's an even shader division; for some reason, I have a 2-card rig on X58 platform that runs better with I:16 (gets 18M on that setting, worse performance with xI), so this may have to do with mobo northbridges.

Awesome; found my best config yet, and v5_0 seems to be building a good kernel now!

= 4.4MH/s.

But if I use xI 256, I get 4.72MH/s!  (Awesome for these fairly gentle overclocks).

---

Conclusion after messing with configs: 
Setting shaders globally is insufficient right now.  When using profiles, I MUST set shaders within the profile, or performance is horrible.

I think you are using xintensity without specifying shaders.

Please try with I:17 worksize 64, no fancy shit, and remove lookup-gap 2

Copying your cl files was my first step that led to this mess in the first place.

aznboy's v5_0-x15 branch is working great tho - 4.56MH/s with:

Exact same config has horrible performance on all the current sgminer-dev branches (stabilizes to 2.77MH/s).

---

Edit: copying the BIN file compiled by the aznboy branch to run on the latest v5_0 sgminer-dev branch produces the best result: 4.62MH/s with the above settings.

So, it's pretty clear that recent changes to sgminer-dev branches break the ability to compile a performant opencl kernel.

I'll do some compiling today to see if I can track down the culprit commits.  In the meantime, thank-you badman, at least this rig is back up to speed again.