OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 647.

The00Dustin

hero member

Activity: 807

Merit: 500

Quote from: -ck on February 17, 2012, 10:17:51 PM

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...

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: -ck on February 17, 2012, 06:36:16 PM

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).

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

Big post

I guess I'll ask ckolivas about putting this into cgminer as a separate file:

AMD-SDK upgrade/downgrade in Linux
==================================
Firstly to install the 2.4 SDK is just as I have said in my linux
USB install script.

My script has exactly the same effect as the cgminer README except
that I copy all the files into the target directories rather than
linking to any of them
(this is mandatory on USB persistent storage coz casper doesn't
keep /opt)

Anyway from the current linux USB script it is:
-----------------------------------------------------------
12) get AMD-APP-SDK-v2.4-lnx64.tgz from
http://developer.amd.com/sdks/amdappsdk/downloads/pages/default.aspx
( http://developer.amd.com/Downloads/AMD-APP-SDK-v2.4-lnx64.tgz )

sudo su
cd /opt
(replace /home/ubuntu/ with wherever you put the file: )
tar -xvzf /home/ubuntu/AMD-APP-SDK-v2.4-lnx64.tgz

cd AMD-APP-SDK-v2.4-lnx64/
cp -pv lib/x86_64/* /usr/lib/
rsync -avl include/CL/ /usr/include/CL/
tar -xvzf icd-registration.tgz
rsync -avl etc/OpenCL/ /etc/OpenCL/
ldconfig
sync
shutdown -r now
-----------------------------------------------------------

I believe SDK 2.5 is exactly the same but replace "2.4" with "2.5"
everywhere - anyone who knows otherwise please tell me.
Also if anyone does know if it is exactly the same please tell
me and I can remove these comments

However, I'm certain it really is exactly the same but have never
touched 2.5

Now 2.4 SDK doesn't touch the drivers that fglrx+++ installs

However, the 2.6 SDK does

So before installing the 2.6 SDK it is best to rename the 2 files
that it overwrites in case you need to go back.
It saves from having to repair the fglrx installs
(which I'd guess is a simple command in apt but I'm not an apt guru)
but it is also so easy to do that it's best just to manually do it.

The two library files are of course in /usr/lib/
   libaticalcl.so libaticalrt.so

IF YOU ARE ALREADY USING FGLRX DRIVER 12.1 OR NEWER:
then you don't want to overwrite libaticalrt.so and libaticalcl.so
So you DON'T want to do 2 steps listed below marked (*A*) and (*B*)

(*A*) If your fglrx is before 12.0:
-----------------------------------------------------------
cd /usr/lib/
sudo mv -v libaticalrt.so libaticalcl.so.old
sudo mv -v libaticalcl.so libaticalcl.so.old
-----------------------------------------------------------

It is mandatory to remove the 2.4 SDK first if you installed it using
ckolivas' README since the first link causes issues - see the bottom of
this for the details of how to remove the 2.4 SDK if you used ckolivas'
README to install it

Next install 2.6 manually so you know exactly what is changed.
Also this means you won't overwrite the fglrx drivers if you
don't want to.

Remember don't do the step below (*B*) if you already have
fglrx 12.1 or newer

To install 2.6 it's:
-----------------------------------------------------------
get AMD-APP-SDK-v2.6-lnx64.tgz from
http://developer.amd.com/sdks/amdappsdk/downloads/pages/default.aspx
  ( http://developer.amd.com/Downloads/AMD-APP-SDK-v2.6-lnx64.tgz )

sudo su
cd /opt
mkdir SDK2.6
cd SKD2.6/
  (replace /home/ubuntu/ with wherever you put the file: )
tar -xvf /home/ubuntu/AMD-APP-SDK-v2.6-lnx64.tgz

tar -xvf AMD-APP-SDK-v2.6-RC3-lnx64.tgz

cd AMD-APP-SDK-v2.6-RC3-lnx64/
cp -pv lib/x86_64/* /usr/lib/
cp -pv lib/*.so /usr/lib/ <- (*B*)

rsync -avl include/CL/ /usr/include/CL/

cd ..
tar -xvzf icd-registration.tgz
rsync -avl etc/OpenCL/ /etc/OpenCL/

ldconfig
sync
shutdown -r now
-----------------------------------------------------------

Now the last part - how to get back to 2.4 from 2.6.

It's not much different except you need to put back the
two old library files if you installed the 2 new ones

IF YOU DIDN'T DO STEPS (*A*) AND (*B*) ABOVE:
then of course you don't need to undo them.
i.e. you don't need to do the 3 steps below marked (*C*)

You of course don't need to repeat the download if you already
have the file.
And you don't need to repeat the 'tar' commands if everything
is still in /opt

To downgrade the 2.6 SDK back to the 2.4 SDK:
-----------------------------------------------------------
12) get AMD-APP-SDK-v2.4-lnx64.tgz from
http://developer.amd.com/sdks/amdappsdk/downloads/pages/default.aspx
  ( http://developer.amd.com/Downloads/AMD-APP-SDK-v2.4-lnx64.tgz )

sudo su

(First cleanup the old 2.6 SDK non-fglrx files)
rm -rvf /usr/include/CL/
rm -rvf /etc/OpenCL/
cd /usr/lib/
rm -v libamdocl64.so libGLEW.so libglut.so libOpenCL.so libOpenCL.so.1 libSlotMaximizerAg.so libSlotMaximizerBe.so

cd /opt
  (replace /home/ubuntu/ with wherever you put the file: )
tar -xvf /home/ubuntu/AMD-APP-SDK-v2.4-lnx64.tgz

cd AMD-APP-SDK-v2.4-lnx64/
cp -pv lib/x86_64/* /usr/lib/
rsync -avl include/CL/ /usr/include/CL/
tar -xvf icd-registration.tgz
rsync -avl etc/OpenCL/ /etc/OpenCL/

cd /usr/lib/ <- (*C*)
mv -v libaticalrt.so.old libaticalcl.so <- (*C*)
mv -v libaticalcl.so.old libaticalcl.so <- (*C*)

ldconfig
sync
shutdown -r now
-----------------------------------------------------------

Edit: added the 2.6 cleanup just in case in the future is causes some problem

Edit2: someone asked how to remove 2.4 ...
If you installed it the way I said to install it then:
-----------------------------------------------------------
sudo su
rm -rvf /usr/include/CL/
rm -rvf /etc/OpenCL/
cd /usr/lib/
rm -v libamdocl64.so libGLEW.so libglut.so libOpenCL.so libOpenCL.so.1
-----------------------------------------------------------

Edit3: how to remove 2.4 if you used ckolivas' README to install it
This will be necessary if you want to upgrade from 2.4 to 2.6 the way I documented
(due to the 1st link):
-----------------------------------------------------------
sudo su
rm -vf /usr/include/CL
rm -rvf /etc/OpenCL/
cd /usr/lib/
rm -v libamdocl64.so libGLEW.so libglut.so libOpenCL.so libOpenCL.so.1
-----------------------------------------------------------
(just the first 'rm' is different coz it's a link not a directory)

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

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?

blandead

newbie

Activity: 46

Merit: 0

Quote from: -ck on February 17, 2012, 05:27:57 AM

Quote from: blandead on February 17, 2012, 05:07:22 AM

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.

It's not losing shares, just takes much longer to deal with them. Any found shares are being stored/loaded to a one component variable, I'm working on a kernel replacing it with (_global uint4 * output) and I can directly work with nonce.xyzw, which is a true 4 vector variable, I am just having trouble figuring out how to pass the found nonces after it's stored. May have to use some kind of loop or "unroll"

Oh yea, glad to see you got GOFFSET to work, btw do you have MAD optimization enabled in your program? There can be a nice speed boost if you do.

jake262144

full member

Activity: 210

Merit: 100

Quote from: DeathAndTaxes on February 17, 2012, 11:28:05 AM

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" ( Huh

with AMD deproved) and keep existing SDK installation.

Definitely deproved Grin

Feeling sorry for Con? Think of the pain AMD people must be going through with those damned faildrivers...
Nothing strange that the CTO of AMD's graphics products group abandoned ship.

dlasher

sr. member

Activity: 467

Merit: 250

Quote from: DeathAndTaxes on February 16, 2012, 10:41:50 PM

Quote from: dlasher on February 16, 2012, 10:31:16 PM

Quote from: -ck on February 15, 2012, 11:34:19 PM

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.

JWU42

legendary

Activity: 1666

Merit: 1000

The latest 12.2 pre has 898.1 SDK (2/16/12 release). I had to manually remove the .dll files and run the 12.1 installer to get the older 854.1 SDK.

Diapolo

hero member

Activity: 769

Merit: 500

Quote from: DeathAndTaxes on February 17, 2012, 11:28:05 AM

Quote from: -ck on February 17, 2012, 11:14:54 AM

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. Angry

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.

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" ( Huh

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 Cheesy

(it looks like they preffer vector GPRs over scalar GPRs with the new runtime as there are massive shifts in GPR usage).

Dia

DeathAndTaxes

donator

Activity: 1218

Merit: 1079

Gerald Davis

Quote from: -ck on February 17, 2012, 11:14:54 AM

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. Angry

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.

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" ( Huh

with AMD deproved) and keep existing SDK installation.

Diapolo

hero member

Activity: 769

Merit: 500

Quote from: -ck on February 17, 2012, 11:14:54 AM

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. Angry

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.

As I said, bad stuff incoming ... here are some version strings from Windows:

platform version: OpenCL 1.1 AMD-APP (898.1)

device infos (verified to be equal on Tahiti and BeaverCreek):
OpenCL software driver version: CAL 1.4.1703 (VM)
supported OpenCL version (FULL_PROFILE): OpenCL 1.1 AMD-APP (898.1)

Dia

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

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. Angry

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.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: Proofer on February 17, 2012, 10:09:17 AM

Quote from: -ck on February 17, 2012, 05:27:57 AM

... 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.

Proofer

member

Activity: 266

Merit: 36

Quote from: -ck on February 17, 2012, 05:27:57 AM

... 99% of users on cgminer are currently using 2 vectors. ...

We p2pool users were advised to use -v 1; are we the 1%?

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Meh, it ended up being of no advantage for unnecessary complexity.

* ckolivas forgets all about goffset for now.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: -ck on February 17, 2012, 06:48:19 AM

Quote from: Diapolo on February 17, 2012, 06:20:02 AM

Quote from: -ck on February 17, 2012, 06:05:02 AM

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 Cheesy

.

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.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: Diapolo on February 17, 2012, 06:20:02 AM

Quote from: -ck on February 17, 2012, 06:05:02 AM

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 Cheesy

.

I'd say you're right. Oh well, always other things to try.

Diapolo

hero member

Activity: 769

Merit: 500

Quote from: -ck on February 17, 2012, 06:05:02 AM

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 Cheesy

.

Dia

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Btw, the performance of it is pretty average, after all that discussion...

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Code:

#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.

Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 647. (Read 5805546 times)