catalyst 12.1 Im flipping tables over it

[Fiyasko]

So has Anyone made it possible for people to run SDK 2.6 and Cat 12.1 to Remove the cpu bug, WITHOUT LOSING 10-20% OF OUR MINING SPEED.
Dia kernal=Nice and easy to use, Has a gui, Only good for 2.6
Phoenix Kern.=Fail, Narks my cpu upto 100%, With bad hashrates
CGminer=Works Annoyingly great
DiabloMiner=A great miner, But Reeaaallly a pain in the ass to work with when it comes to finding what args/flags work best, All in all, I failed at finding them


win7x64
crossfire 6870's 1000core
PhenomIIx6.1090T@3.4
Cat 12.1 SDK 2.6

If your able to solve my troubles, I may kick coins over your way, Linking me to a solution gets you a minimal amount of reward.
Clearly, It is I whom is fucking up. Theres no way that swapping kernals should Shit all over my system like this.

Holliday has helped me into solution.

[grue]

copy OpenCL.dll from 2.1 to cgminer's directory.

[Fiyasko]

copy OpenCL.dll from 2.1 to cgminer's directory.

.. Really?.. And could you elaborate just a bit more, Simply in the base directory and nothing special? No driver changes or commands to tell CG to detect it?, It'll just go off without any issues?

win7x64

[deepceleron]

Has anyone found a way to have new drivers installed, To fix the cpu bug and play games, Without losing mh/s performance?

Why yes, all you had to do was look: AMD Stream SDK 2.6 (Catalyst 11.12/12.1) - Get your performance back! (Phoenix)

[Fiyasko]

Has anyone found a way to have new drivers installed, To fix the cpu bug and play games, Without losing mh/s performance?

Why yes, all you had to do was look: AMD Stream SDK 2.6 (Catalyst 11.12/12.1) - Get your performance back! (Phoenix)

I tried that... It doesnt work for me very well. Brings my core upto 50% per gpu, and doesnt bring back the mh/s performance...  

[grue]

.. Really?.. And could you elaborate just a bit more, Simply in the base directory and nothing special? No driver changes or commands to tell CG to detect it?, It'll just go off without any issues?

win7x64

i know from msdn that placing a dll in the same directory as a executable will cause the program to load that dll instead of the one in system32 or syswow64.

The first directory searched is the directory containing the image file used to create the calling process

and i made an educated guess that if the dll for opencl was replaced, the opencl version would effectively be replaced as well. Not entirely sure though. the only real way is to try it yourself 

if you want, i can send the dlls from 2.1 sdk

[Fiyasko]

.. Really?.. And could you elaborate just a bit more, Simply in the base directory and nothing special? No driver changes or commands to tell CG to detect it?, It'll just go off without any issues?

win7x64

i know from msdn that placing a dll in the same directory as a executable will cause the program to load that dll instead of the one in system32 or syswow64.

The first directory searched is the directory containing the image file used to create the calling process

and i made an educated guess that if the dll for opencl was replaced, the opencl version would effectively be replaced as well. Not entirely sure though. the only real way is to try it yourself 

if you want, i can send the dlls from 2.1 sdk

lets try 2.5 since i dont hear complaints about performance loss (aside from that 2/1%)

[Fiyasko]

yeah i did see them

[Fiyasko]

https://bitcointalk.org/index.php?topic=28402.msg688286#msg688286

ooouuu

[jake262144]

i know from msdn that placing a dll in the same directory as a executable will cause the program to load that dll instead of the one in system32 or syswow64.

Not so fast, Cowboy
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586%28v=vs.85%29.aspx

Pay close attention to the folowing point:
If a DLL with the same module name is already loaded in memory, the system uses the loaded DLL, no matter which directory it is in. The system does not search for the DLL.


Copying the file into application directory is not enough if the library from SDK 2.6 has already been loaded into memory. System reboot is mandatory.
Only then can you guarantee that the correct library will be used.
There are of course ways to forcefully unload a library without rebooting the machine but they are geeky, thus hard to recommend to the general public.

[deepceleron]

i know from msdn that placing a dll in the same directory as a executable will cause the program to load that dll instead of the one in system32 or syswow64.

Not so fast, Cowboy
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586%28v=vs.85%29.aspx

Pay close attention to the folowing point:
If a DLL with the same module name is already loaded in memory, the system uses the loaded DLL, no matter which directory it is in. The system does not search for the DLL.


Copying the file into application directory is not enough if the library from SDK 2.6 has already been loaded into memory. System reboot is mandatory.
Only then can you guarantee that the correct library will be used.
There are of course ways to forcefully unload a library without rebooting the machine but they are geeky, thus hard to recommend to the general public.

In my experience, the DLLs are only locked and loaded when an OpenCL application is running. You can shut down your miner, replace the files, restart your miner, and immediately see the different hash rate of the other SDK.

[Fiyasko]

Annnnnnnnnnnnnd is anyone going to upload said needed .dll's with some instructions as to where to place them to get them to work with what.
Or am i just going to have to figure all that bullshit out for myself... Cause i dont damnwell know how to pulll a .dll out of the damn SDK install packages...

Best idea i'v-- No thats not even an idea, I dont even know what im looking for, Or where the fuck to look for it, OR WHAT TO DO WITH IT EVEN IF IM HOLDING IT *tosses 50billion dollar peice of legendary relic behind him not knowing what it is and assumed it was just another dusty peice of junk as he continues to search for the legendary ".dll" (lol)*

[jake262144]

In my experience, the DLLs are only locked and loaded when an OpenCL application is running. You can shut down your miner, replace the files, restart your miner, and immediately see the different hash rate of the other SDK.

If you haven't set the AlwaysUnloadDll registry key under HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows/CurrentVersion/Explorer, Windows might very well leave the library in RAM.
Windows Vista and 7 do tremendous amounts of caching and unless unused system RAM is very low they won't automatically unload for efficiency's sake.
That's a nice behavior for an OS to be actually making use of those gigabytes of inexpensive RAM.
I can't find the specific kb article right now; I'll update with a link if I find it.

[antares]

hi there,

I'm not sure this is going to work for you, however on my linux rig I was affected by the 100% bug when using Catalyst >12.1 and AMD APP 2.6. I noticed on a quick glance that the problem was pyOpenCL(I got suspicious when running hashkill, which did not have the bug). So I tried using an older version of pyOpenCL which I compiled myself, and it resolved the issue without any impact on my mining performance. I then had a friend mining on windows who complained about the 100% issue himself, and I told him that using a selfcompiled pyOpenCL did solve the problem. He then went on and installed python, a self built windows version of pyOpenCL and ran poclbm himself on windows. (manually without GUIminer). this solved the 100% bug for him as well, without hurting performance. So you might just try doing that if you have some beer and experience to do this. However, no guarantee here, since I only have what my pal reported back to me ...

[deepceleron]

hi there,

I'm not sure this is going to work for you, however on my linux rig I was affected by the 100% bug when using Catalyst >12.1 and AMD APP 2.6. I noticed on a quick glance that the problem was pyOpenCL(I got suspicious when running hashkill, which did not have the bug). So I tried using an older version of pyOpenCL which I compiled myself, and it resolved the issue without any impact on my mining performance. I then had a friend mining on windows who complained about the 100% issue himself, and I told him that using a selfcompiled pyOpenCL did solve the problem. He then went on and installed python, a self built windows version of pyOpenCL and ran poclbm himself on windows. (manually without GUIminer). this solved the 100% bug for him as well, without hurting performance. So you might just try doing that if you have some beer and experience to do this. However, no guarantee here, since I only have what my pal reported back to me ...

Phoenix 1.7.3 win32 exe reports that it is using pyOpenCL 2011.1beta; I believe 0.98 was used in older versions, so this may help multi-cpuers. (Note: Jedi95 fixed, no difference in hashrate)

It seems that early reports "11.12 solves CPU bug" may have been premature, as we can see many still have the problem depending on OS, hardware, and miner.

[Fiyasko]

Annnnnnnnnnnnnd is anyone going to upload said needed .dll's with some instructions as to where to place them to get them to work with what.
Or am i just going to have to figure all that bullshit out for myself... Cause i dont damnwell know how to pulll a .dll out of the damn SDK install packages...

Best idea i'v-- No thats not even an idea, I dont even know what im looking for, Or where the fuck to look for it, OR WHAT TO DO WITH IT EVEN IF IM HOLDING IT *tosses 50billion dollar peice of legendary relic behind him not knowing what it is and assumed it was just another dusty peice of junk as he continues to search for the legendary ".dll" (lol)*

Goodness.

Install newest drivers.

Go here https://bitcointalk.org/index.php?topic=54693.msg651989#msg651989 and get the files.

Go to C:\Windows\System32 and C:\Windows\SysWOW64 and replace the appropriate files. Save the originals if you want to switch back to sdk 2.6. You should run windows explorer as administrator and not have any mining software running when replacing. Sometimes there are only 2 files per folder, sometimes 3.

Download the newest cgminer. Or use the cgminer you already have but browse to the folder and delete the .bin files before starting it.

Start cgminer and enjoy good hash rates and no CPU usage.

Shut down cgminer.

Replace the .dlls with the originals if you want sdk 2.6 back.

Run cgminer again. DO NOT delete the .bin file. You should still have your good hash rate and no CPU usage.

If you update cgminer, you will probably have to repeat this process as it will build new binaries with the newer, slower sdk. So save the 2.5 .dlls.

So whats your bitcoin address?

[Fiyasko]

So whats your bitcoin address?

Are you saying it worked?

If so, and if you are offering me a reward, I ask instead that you switch from wherever you are mining to p2pool for at least a week. It's fairly easy to set up, even easier if you already have the newest version of Bitcoin installed with an up-to-date block chain. I could even attempt to help you if you ran into trouble, but I'm not very knowledgeable on the subject (although I am mining in p2pool).

If you are opposed to this idea, I will accept your donation at 14NwYbaZ8D3NNyUSVN4z357k9BhZBErjYd and redistribute it to the miners of P2Pool.

Thanks.

How large is the P2Pool hashrate sofar? Last time i checked it was a meager 5xgigahashes...
The only reason i stay in the pools is because the Variance is So, Sooo much lower.

[Fiyasko]

So whats your bitcoin address?

Are you saying it worked?

If so, and if you are offering me a reward, I ask instead that you switch from wherever you are mining to p2pool for at least a week. It's fairly easy to set up, even easier if you already have the newest version of Bitcoin installed with an up-to-date block chain. I could even attempt to help you if you ran into trouble, but I'm not very knowledgeable on the subject (although I am mining in p2pool).

If you are opposed to this idea, I will accept your donation at 14NwYbaZ8D3NNyUSVN4z357k9BhZBErjYd and redistribute it to the miners of P2Pool.

Thanks.

How large is the P2Pool hashrate sofar? Last time i checked it was a meager 5xgigahashes...
The only reason i stay in the pools is because the Variance is So, Sooo much lower.

The pool is small, because of the very reason you bring up. Miners don't switch, so the pool stays small. It's around 70Ghash/s and solving approximately one block a day. But there are also a few people making daily donations to the miners of P2Pool according to how many shares you've submitted in a certain time frame.

I understand if you don't want to switch. But miners need to realize that putting the majority of the mining power in the hands of a few could potentially hurt the network in the future, resulting in paychecks for no one.

That, And the fact that anyone thats in a taxed pool is creating a "fatcat" with alot of money
Im confident that im about 15% away from having P2Pool running

[grue]

so what's the point of replacing the system32/syswow64 dlls? doing that forces every application to use the older sdk, which may reduce performance for other programs, like games. placing the dlls with the miner executable is the safest option, imo.

[Fiyasko]

so what's the point of replacing the system32/syswow64 dlls? doing that forces every application to use the older sdk, which may reduce performance for other programs, like games. placing the dlls with the miner executable is the safest option, imo.

Well i was never given a straight answer as to weather or not/ where to drop the files/what files near/in cgminer to make it use the other dlls
Whereas this answer was confimred by many