Yes, I do have it change the settings. Here's my command line: cgminer -o http://127.0.0.1:9332 -u xxx-p xxx--auto-gpu --gpu-engine 750-960 --gpu-memclock 250 --temp-target 80 --gpu-vddc 1.1 -g 1 But did you reboot or manually set them back after using the previous version that didn't set them back due to the crash? CGMINER sets them back to where they were when it started, it doesn't know the defaults. I set them back to their mfg defaults using the Catalyst Control Center, then ran cgminer to see if it restored them (which it didn't). Shafted. |
|
|
|
Yes, I do have it change the settings. Here's my command line: cgminer -o http://127.0.0.1:9332 -u xxx-p xxx--auto-gpu --gpu-engine 750-960 --gpu-memclock 250 --temp-target 80 --gpu-vddc 1.1 -g 1 But did you reboot or manually set them back after using the previous version that didn't set them back due to the crash? CGMINER sets them back to where they were when it started, it doesn't know the defaults. This is correct, it assumes you have set certain values for a reason before it starts up its code. It reads off your profile as cgminer is started, and then on exit it writes back the profile that was there before it started. The only thing it sets to "default" behaviour is the fan management. |
|
|
|
More AMD breakage coming up. As Diapolo hinted earlier, there is a new AMD driver 12.2 with an SDK that claims to be sdk 2.6 but comes up with the version number 898.1. It breaks cgminer completely making it unable to build any binaries.  I have yet to investigate why but please do not upgrade unless you already have .bin files that work. I'm going to start a collection of bin files that people may be able to download and they'll be housed here: Alternatively you could install upgrade but (in windows) select custom install and UNCHECK SDK. Not sure if 12.2 has any notable changes compared to 12.1 but if it does that is way to get "improved" (  with AMD deproved) and keep existing SDK installation. Yes, for now one should uncheck OpenCL Runtime during Catalyst upgrade until CGMINER is fixed. My first look made me scream on another fact, they did heavy work on their OpenCL compiler, which tends to behave again very differently compared to former versions ... seems like more work in the future  (it looks like they preffer vector GPRs over scalar GPRs with the new runtime as there are massive shifts in GPR usage). Well I believe I've fixed this in my git tree, and I've uploaded an exe into that temp directory as always. If someone is brave enough to try the latest driver 12.2 with its sdk on 64 bit windows with this executable I'd be mighty grateful: http://ck.kolivas.org/apps/cgminer/temp/cgminer.exe |
|
|
|
I started and stopped it like 10 times and it didn't crash. Isn't supposed to restore the GPU settings though? It still leaves the GPU at its mining settings (a minor inconvenience). Yes it is supposed to restore the GPU settings. Though that's only if you actually make it change any settings when you start it. It does not try to restore anything if it never adjusted any settings to begin with. |
|
|
|
What does long4 vs. long8 mean in the .bin filename?
Sam
Notably there are Tahiti (7970) .bins for 32 bit (long4) and 64 bit (long8)
|
|
|
|
cgminer sets clocks all back to default on exit... if it exits cleanly, and of course on windows it's a miracle when it does.
Sadly this is not the case. windows machine, pair of 6950's, set to 850/1300 for normal operation, in cgminer they are set to 700-880/300... when cgminer exits it leaves the cards at 880/300. even updated to 12.1 drivers, both 2.4 and 2.6 SDK. Is it exiting or crashing? I run cgminer from a .bat file in windows, and when I hit the "Q" button, it gives me the 2-page summary of stats, then sits for about 3 seconds and then closes the dos window. I'm not getting any complaints from windows about it crashing/hanging/etc. ckolivas: I know you have the impossible task of trying to make an app play nice with windows. I'm HAPPY to run any sort of debug load/options you might have to give better/more-detailed information. It should not be closing the dos window... there's still something going wrong. Try the experimental binary http://ck.kolivas.org/apps/cgminer/temp/cgminer.exeThis one tries to reset GPU settings before trying to shut down so that even if it crashes/hangs on exit, your GPUs should go to default values. |
|
|
|
How do people feel about me providing "optimal bins" included as a separate "full package" with cgminer?
I figure 2.4/2.5 bins for vliw4 (R6xxx), 2.1 bins for vliw5 (R5xxx) and 2.6 bins for GCN (R7xxx). If you do this and cgminer automatically uses the best one, you might get lonely when newbs stop posting about how the latest update slowed them down... LOL that's my kind of ronery. |
|
|
|
I'm trying to get together a collection of binaries for different hardware from different SDKs. If anyone has binaries for the different SDKs, please check http://ck.kolivas.org/apps/cgminer/bins/ to see if they exist and if not, can you send me a copy? Thanks everyone who promptly sent me their binaries! I now have a collection in the cgminer directory that people can download if they're having issues with their SDKs. How do people feel about me providing "optimal bins" included as a separate "full package" with cgminer? I figure 2.4/2.5 bins for vliw4 (R6xxx), 2.1 bins for vliw5 (R5xxx) and 2.6 bins for GCN (R7xxx). |
|
|
|
I'm trying to get together a collection of binaries for different hardware from different SDKs. If anyone has binaries for the different SDKs, please check http://ck.kolivas.org/apps/cgminer/bins/ to see if they exist and if not, can you send me a copy? |
|
|
|
More AMD breakage coming up. As Diapolo hinted earlier, there is a new AMD driver 12.2 with an SDK that claims to be sdk 2.6 but comes up with the version number 898.1. It breaks cgminer completely making it unable to build any binaries. I have yet to investigate why but please do not upgrade unless you already have .bin files that work. I'm going to start a collection of bin files that people may be able to download and they'll be housed here: http://ck.kolivas.org/apps/cgminer/bins/Notably there are Tahiti (7970) .bins for 32 bit (long4) and 64 bit (long8) as these depend on sdk2.6 and people may well get a nasty surprise if they try to get it working now with the latest drivers. |
|
|
|
... 99% of users on cgminer are currently using 2 vectors. ...
We p2pool users were advised to use -v 1; are we the 1%? No, you were advised to use -g 1 I don't recall saying to use one vector for p2pool and if anyone did say that, they're wrong. |
|
|
|
Meh, it ended up being of no advantage for unnecessary complexity. * ckolivas forgets all about goffset for now. |
|
|
|
Btw, the performance of it is pretty average, after all that discussion...
Perhaps the changes needed to make it work ate the small benefits the solution offers ... but I had to LOL when I saw we came up with the same solution ^^. I posted and read your version after that and they look equal for VEC2 . I'd say you're right. Oh well, always other things to try. You know I could make cgminer "skip" nonce ranges when it's using goffset so that the code can work with less ops. This will drop efficiency though since it will decrease the amount of work a device gets before it needs new work. |
|
|
|
Btw, the performance of it is pretty average, after all that discussion...
Perhaps the changes needed to make it work ate the small benefits the solution offers ... but I had to LOL when I saw we came up with the same solution ^^. I posted and read your version after that and they look equal for VEC2 . I'd say you're right. Oh well, always other things to try. |
|
|
|
|
Btw, the performance of it is pretty average, after all that discussion...
|
|
|
|
#if defined VECTORS4
#ifdef GOFFSET
u nonce = (uint)get_global_id(0) + (u)(0, get_global_size(0), get_global_size(0) << 1, get_global_size(0) * 3);
#else
u nonce = ((uint)get_group_id(0) * (uint)get_local_size(0) << 2) + ((uint)get_local_id(0) << 2) + base;
#endif
#elif defined VECTORS2
#ifdef GOFFSET
u nonce = (uint)get_global_id(0) + (u)(0, get_global_size(0));
#else
u nonce = ((uint)get_group_id(0) * (uint)get_local_size(0) << 1) + ((uint)get_local_id(0) << 1) + base;
#endif
#else
should do it and cgminer already takes vectors into account when increasing nonce value to pass to base on the next pass. This doesn't change it. cgminer effectively sends twice as much work when vectors go from 1 to 2 so the intensity is effectively different at different vectors. |
|
|
|
For -v 2 it should halve the global worksize (global Threads) number, so doubling this in the kernel should be no problem at all, right?
global_id == global_work_offset + global_worksize You're doubling the global id, not the worksize. Global ID without global offset is: 0 till (global worksize - 1) queried in the kernel via get_global_size(0). So for 2-component vectors we need a global worksize / 2 (as argument in the enqueue kernel call), because there are 2 nonces processed in each work-item. Global ID with global offset is: global offset till (global worksize + global offset - 1). Dia I still think it should be something like: u nonce = ((uint)get_global_id(0) + get_global_size(0) * (0,1,2,3)); for vectors4 etc. Thinking loud again: get_global_id(0) == ranges from global_offset for the 1st work-item till (global_offset + (global_worksize - 1)) for the last work-item get_global_size(0) == global_worksize (constant value) global_offset == nonce-base, that results in: nonce.x = nonce-base + global_worksize * 0; nonce.y = nonce-base + global_worksize * 1; nonce.z = nonce-base + global_worksize * 2; nonce.w = nonce-base + global_worksize * 3; Let's consider 10 as nonce-base and 4 as global_worksize. This leads to the following nonces that get checked during 1 kernel execution: Work-Item 0: 10 + 4 * 0 = 10 10 + 4 * 1 = 14 10 + 4 * 2 = 18 10 + 4 * 3 = 22 Work-Item 1: 11 + 4 * 0 = 11 11 + 4 * 1 = 15 11 + 4 * 2 = 19 11 + 4 * 3 = 23 Work-Item 2: 12 + 4 * 0 = 12 12 + 4 * 1 = 16 12 + 4 * 2 = 20 12 + 4 * 3 = 24 Work-Item 0: 13 + 4 * 0 = 13 13 + 4 * 1 = 17 13 + 4 * 2 = 21 13 + 4 * 3 = 25 So we have nonces from 10 to 25 Now if we divide the passed global worksize by 4 (because of 4-component vector usage in your example) and use 1 for it this leads to: Work-Item 0: 10 + 1 * 0 = 10 10 + 1 * 1 = 11 10 + 1 * 2 = 12 10 + 1 * 3 = 13 So I guess your code works, if you divide the global worksize by the vec-size before passing that argument to clEnueueNDRangeKernel. Thanks. My issue with your code being: u nonce = ((uint)get_global_id(0) << 2) + (u)(0, 1, 2, 3);
as I said is it really won't be testing the nonce range we're asking it to test. If "base" is 2^31 and worksize is 2^24 (intensity 9), then get_global_id(0) will return 2^31 for the very first thread. Then if we shift it << 2 it's going to be undefined and in most implementations will just be zero again. Which means we'll be repeating 2^24 operations on nonces 0 - 2^24, which we would have done initially on getting that work item. |
|
|
|
If you're trying to use vectors then there is a type mis-match either stick with putting a (u) in front or use (uint4) and the (0, 1, 2, 3) should be on the outside parenthesis.
Here is a float4 example...
float4 f = (float4)(1.0f, 2.0f, 3.0f, 4.0f);
Also in the _kernal void search if you keep (_global uint * output) then you're not really utilizing vectors correctly
And, sorry was just trying to provide some general feedback with Out of Order Execution, wasn't trying to offend you, I'm just not sure how to edit cgminer directly.
Thanks. Are you saying the existing code is losing shares with __global uint * output? 99% of users on cgminer are currently using 2 vectors. Again I doubt that's the case. |
|
|
|
|
Show Posts
