OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1

[BCMan]

Of course it is.
Add those to your config file:

Code:

"intensity" : "9,9,8,9",
"vectors" : "2",
"worksize" : "64",

Intensity is the same as Aggression in phoenix nomanclature. With cgminer you are use a per-card value as shown in the example code. Don't use values hight than 9 unless using a 7970 card.
You don't need to specify BFI_INT, it's on by default.

Also, RTFM - that info is in the readme file and in the very first post of this thread.

Thanks, but how to change platform? I need 2.1 instead of 2.5 sdk (getting cpu bug with 2.5). 2.5 installed as platform=0 (used by cgminer by default), 2.1 at 1.

[DeathAndTaxes]

Of course it is.
Add those to your config file:

Code:

"intensity" : "9,9,8,9",
"vectors" : "2",
"worksize" : "64",

Intensity is the same as Aggression in phoenix nomanclature. With cgminer you are use a per-card value as shown in the example code. Don't use values hight than 9 unless using a 7970 card.
You don't need to specify BFI_INT, it's on by default.

Also, RTFM - that info is in the readme file and in the very first post of this thread.

Thanks, but how to change platform? I need 2.1 instead of 2.5 sdk (getting cpu bug with 2.5). 2.5 installed as platform=0 (used by cgminer by default), 2.1 at 1.

I don't think you can.  Simple solution it to removed 2.5 SDK.

[jake262144]

No need to remove anything.
Just copy the 2.1 SDK libraries into cgminer's directory and you're done!
You need the following files:

Code:

amdocl.dll
amdoclcl.dll
OpenCL.dll

A reboot might be necessary if Windows doesn't want to unload the previously-used 2.5  SDK libraries from memory.

[DeathAndTaxes]

Nice workaround but give how crappy 2.5 is I see no reason to keep it.  Likely time will go by user forgets, installs new copy of cgminer (or different miner) and doesn't realize it is now  re-using the worthless 2.5.

[-ck]

I'm not using cgminer with any nvidia cards, but if it is supposed to support them, you might want to do this in your next update:

I have not tested Ufasoft or cgminer, but there's no problem with Phoenix.
(using Nvidia driver 285.62 with Win 7 64Bit)

Edit: Ufasoft 64Bit doesn't see the graphics card, 32Bit is working fine.

Fixed, please redownload Windows binary.

Really it seems a bug in CUDA. by some reason x64 CUDA incorrectly interprets following construct:

Code:

__constant uint L = 0x98c7e2a2;

Replaced to :

Code:

__constant uint L[1] = { 0x98c7e2a2 };

And it works now!

Note that a few pots up someone points out that that nvidia driver version breaks it in cgminer as well, implying that it is supposed to support them, and I don't know if this is Win only or not.

Hmm thanks for the link, but that doesn't even appear in my code anywhere. Presumably that's ufa they're talking about. Meanwhile cgminer mines fine on my nvidia laptop so 

[jake262144]

Nice workaround but give how crappy 2.5 is I see no reason to keep it...

Dependency hell, DAT.
2.6 is extremely crappy but necessary for running 7xxx cards.
2.5 and 2.4 are less crappy and required for 69xx cards.
2.1 is the best SDK version unless you limnit yourself to VLIW5 architecture cards.

What miners should really do is organize their GPUs in groups by required SDK version.
Mixing VLIW4 and VLIW5 cards is a waste of hash rate, adding GCN to the bunch - a criminal waste

[-ck]

The reorder branch has now been merged into the master git branch. Putting the finishing touches on the code, readme etc. to release the new version today.

WARNING
This means that the ordering of your cards will almost certainly change from here on with cgminer into the "correct" order based on physical bus ID location so if you have different settings for different GPUs, you will need to update all your configuration files accordingly.

[jake262144]

Acknowledged and thank you. Testing latest git version right now.

[kano]

Nice workaround but give how crappy 2.5 is I see no reason to keep it...

Dependency hell, DAT.
2.6 is extremely crappy but necessary for running 7xxx cards.
2.5 and 2.4 are less crappy and required for 69xx cards.
2.1 is the best SDK version unless you limnit yourself to VLIW5 architecture cards.

What miners should really do is organize their GPUs in groups by required SDK version.
Mixing VLIW4 and VLIW5 cards is a waste of hash rate, adding GCN to the bunch - a criminal waste

Um ... ?

2.4 for 69xx cards - where's it "crappy"?

(unless of course you mean the entire ATI 'crappy' - well you can't avoid that no matter what you do coz every version is from them)

How is 2.1 better than 2.4? (I have no idea myself - that's just an extra question thrown in that would be worth answering since you said it)

[DeathAndTaxes]

How is 2.1 better than 2.4?

2.1 seems to be the "common wisdom" as best SDK for 5000 series but I don't see any difference between 2.4 and 2.1 w/ my 5970s.  

Actually the rig w/ 2.4 produced 0.7% more shares over last week but that likely is just variance.  Lets call it a tie.

Now 2.5 2.6 is garbage.  Super garbage.  If you have a 7000 series rig it should only have 7000 series because you need the crap 2.5 2.6.

I think what sometimes confuses people is driver is bundled w/ an SDK version.  So for example some of the drivers which were bundled w/ SDK after 2.1 had 100% CPU bug.  It had nothing to do w/ the SDK but that whole release gets dragged down.

Still AMD does need to work on their drivers & SDKs  

[-ck]

How is 2.1 better than 2.4?

2.1 seems to be the "common wisdom" as best SDK for 5000 series but I don't see any difference between 2.4 and 2.1 w/ my 5970s. 

Actually the rig w/ 2.4 produced 0.7% more shares over last week but that likely is just variance.  Lets call it a tie.

Now 2.5 is garbage.  Super garbage.  If you have a 7000 series rig it should only have 7000 series because you need the crap 2.5. 

I assume you mean 2.6 is garbage. 2.5 worked identically to 2.4 in my experience.

[-ck]

Acknowledged and thank you. Testing latest git version right now.

Apologies, this order change did not benefit linux which usually showed the correct order, it only swapped the order around, so I'll be disabling it from linux and only using it on windows.

[DeathAndTaxes]

I assume you mean 2.6 is garbage. 2.5 worked identically to 2.4 in my experience.

Yes. 

DOH.

[-ck]

Anyone who's ever coded crossplatform will have to laugh at this, so I just had to share it.

Code:

+#ifdef WIN32
                        if (adapters[j].iBusNumber < adapters[i].iBusNumber)
+#else
+                       if (adapters[j].iBusNumber > adapters[i].iBusNumber)
+#endif

[-ck]

New release: Version 2.2.0

NOTE: GPU Device order may change with this release with ATI GPUs as cgminer
now can enumerate them according to their Bus ID which means the values should
now correlate with their physical position on the motherboard.


Links in top post as always.

Given the number of changes in this version, I have a human readable summary of user-visible changes first. CPU mining binaries will no longer be distributed by myself:

New features:
Bitforce FPGA support
Net Delay option to not overload slow routers
Socks proxy support.
More RPC API interfaces
Preliminary GCN support
Linking of fan speed and control on dual GPU cards.

Changes:
Reordering of devices where possible to match PCI order.
Intensity support up to 14
Better damping of fanspeed with auto-fan
GPU temperature of 2nd GPU in dual GPU  cards affects fanspeed
CPU mining being deprecated and off by default
Parsing of configuration files copes much better with problems
Less false positives for network delays.

Bugfixes:
Much less likely to fail to build binaries on first startup. (completely fixed?)
Fixed potential for false positive of a dead pool.

New bugs:
Unknown  

Full changelog:
- Default to poclbm kernel on Tahiti (7970) since phatk does not work, even
though performance is sub-standard so that at least it will mine successfully by
defau
- Retain cl program after every possible place we might build the program.
- Update ADL SDK URL.
- Fix potential overflow.
- Map GPU devices to virtual devices in their true physical order based on
BusNumber.
- Change the warning that comes with failure to init cl on a device to be more
generic and accurate.
- Advertise longpoll support in X-Mining-Extensions
- Detect dual GPU cards by iterating through all GPUs, finding ones without
fanspeed and matching twins with fanspeed one bus ID apart.
- Do not attempt to build the program that becomes the kernel twice. This could
have been leading to failures on initialising cl.
- Some opencl compilers have issues with no spaces after -D in the compiler
options.
- Allow intensity up to 14.
- Use calloced stack memory for CompilerOptions to ensure sprintf writes to the
beginning of the char.
- Whitelist 79x0 cards to prefer no vectors as they perform better without.
- Adjust fan speed gently while in the optimal range when temperature is
drifting to minimise overshoot in either direction.
- Detect dual GPU cards via the indirect information of - 1st card has a fan
controller. 2nd card does not have a fan controller, cards share the same device
name
- Instead of using the BFI_INT patching hack on any device reporting
cl_amd_media_ops, create a whitelist of devices that need it. This should enable
GCN architec
- Fixed API compiling issue on OS X
- Add more explanation of JSON format and the 'save' command
- Return an error if using ADL API commands when it's not available
- Read off lpThermalControllerInfo from each ADL device.
- Add ADL_Overdrive5_ThermalDevices_Enum interface.
- Add API commands: config, switchpool, gpu settings, save
- Implement socks4 proxy support.
- Fix send() for JSON strings
- Introduce a --net-delay option which guarantees at least 250ms between any
networking requests to not overload slow routers.
- Generalise locking init code.
- Allow invalid values to be in the configuration file, just skipping over them
provided the rest of the file is valid JSON. This will allow older configurat
- Allow CPU mining explicitly enable only if other mining support is built in.
- BitForce FPGA support
- Configure out building and support of all CPU mining code unless
--enable-cpumining is enabled.
- Allow parsed values to be zero which will allow 0 values in the config file to
work.
- Advertise that we can make our own midstate, so the pool can skip generating
it for us
- Refactor the CPU scanhash_* functions to use a common API. Fixes bugs.
- Don't consider a pool lagging if a request has only just been filed. This
should decrease the false positives for "pool not providing work fast enough".
- Invalidating work after longpoll made hash_pop return no work giving a false
positive for dead pool. Rework hash_pop to retry while finds no staged work u
- Remove TCP_NODELAY from curl options as many small packets may be contributing
to network overload, when --net-delay is enabled.
- Refactor miner_thread to be common code for any kind of device
- Simplify submit_nonce loop and avoid potentially missing FOUND - 1 entry.
Reported by Luke-Jr.
- Micro-optimisation in sha256_sse2 code courtesy of Guido Ascioti
- Refactor to abstract device-specific code

[cablepair]

How is 2.1 better than 2.4?

2.1 seems to be the "common wisdom" as best SDK for 5000 series but I don't see any difference between 2.4 and 2.1 w/ my 5970s. 

Actually the rig w/ 2.4 produced 0.7% more shares over last week but that likely is just variance.  Lets call it a tie.

Now 2.5 is garbage.  Super garbage.  If you have a 7000 series rig it should only have 7000 series because you need the crap 2.5. 

I assume you mean 2.6 is garbage. 2.5 worked identically to 2.4 in my experience.

awesome!

Since this topic is hot right now - let me pop this question

Which SDK is best for 5xxx and which SDK is best for 6xxx

can we get a point of reference here? Thanks!

[DeathAndTaxes]

A totally monster update.  Kudos.
Donation heading your way as soon as I earn some coins. 

BTW:  BAMT + cgminer (w/ RPC) = hashing farm wonderland.

[DeathAndTaxes]

Since this topic is hot right now - let me pop this question

Which SDK is best for 5xxx and which SDK is best for 6xxx

can we get a point of reference here? Thanks!

I think this is less of an issue now.  In my experience 2.1, 2.3, & 2.4 all perform the same for 5000 series cards.  Now when the CPU bug existed the 5000 series cards could use older DRIVER to escape it and they came w/ 2.1 SDK.  However w/ CPU bug fixed that is less of an issue.

2.6 significantly (15%+) underperforms 2.1, 2.3, 2.4. I never used 2.5 simply because I stopped upgrading when things weren't broke.  AMD taught me to fear new driver & SDK versions.

Since cgminer will use the SDK in local directory you can test them all yourself if you want by copying DLL for each SDK one at a time into locally directory and running cgminer for say a couple hours.

[-ck]

Some people say the 5xxx cards were faster with SDK 2.1, however this changed with the phatk2+ kernel in cgminer, where 2.1, 2.4 and 2.5 are pretty much equal. 2.2 and 2.3 have various problems with various kernels and various hardware, the details of which I don't know. 2.6 is basically crap for everything but 7970, where it's mandatory.

[DeathAndTaxes]

Hey ckolivas?  Does the AMD API expose the SDK version?  If so then the program could check at runtime and display it with miner version.

cgminer 2.20 (SDK 2.5)

It might help in troubleshooting users who show bad performance and swear they haven't upgraded drivers.  "Well cgminer says it is running on v2.6 so ".