catalyst 12.1 Im flipping tables over it

Fiyasko

legendary

Activity: 1428

Merit: 1001

Okey Dokey Lokey

Quote from: ?? on ??

They build when you first run cgminer. If you haven't ran a new version of cgminer yet, you won't have a .bin file yet.

Anyway, you want to run cgminer the first time with the 2.5 sdk .dlls in the folders.

After you do that, you can replace the 2.5 sdk .dlls with 2.6, but cgminer will run as if you still have the 2.5.

Quote from: ?? on ??

Quote from: Fiyasko on January 14, 2012, 12:20:29 AM

What .bin file, There isnt, And has never been one

In the cgminer folder.

See the .bin files?

PFFFFFFFFFAHAHAHAHHAHAHHAA
GPU 0: 82.0C 98% | 318.3/318.0Mh/s | A: 8 R:0 HW:0 U:2.28/m I: 3
GPU 1: 77.0C 96% | 319.0/318.2Mh/s | A:15 R:0 HW:0 U:4.28/m I: 3
^I knew SDK2.6 wasnt getting me this, THANKYOU HOLIDAY
*snickers and facepalms* Mygosh.. Heres what i could see.

Fiyasko

legendary

Activity: 1428

Merit: 1001

Okey Dokey Lokey

What .bin file, There isnt, And has never been one

Fiyasko

legendary

Activity: 1428

Merit: 1001

Okey Dokey Lokey

Quote from: deepceleron on January 13, 2012, 01:57:42 PM

Quote from: jake262144 on January 12, 2012, 06:22:22 PM

Quote from: grue on January 08, 2012, 11:16:34 PM

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.

This is exactly what im trying to achieve, But, How do i get CGMiner/ my comp to detect that the .dll's are there? I put them there, Rebooted for shits, No differance

Fiyasko

legendary

Activity: 1428

Merit: 1001

Okey Dokey Lokey

So WHERE do i place the 2.1/2.4/2.5 .dll's for CGMiner? Where in it's directory..

I do not want to change my sys32/wow64 sdk dll's because that changes the whole sdk rather than tweaking the comp's miner to use an older sdk's .dll's

How do you make CGMiner use the older files?

Fiyasko

legendary

Activity: 1428

Merit: 1001

Okey Dokey Lokey

Quote from: grue on January 13, 2012, 08:10:32 PM

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

grue

legendary

Activity: 2058

Merit: 1452

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

legendary

Activity: 1428

Merit: 1001

Okey Dokey Lokey

Quote from: ?? on ??

Quote from: Fiyasko on January 13, 2012, 07:19:03 PM

Quote from: ?? on ??

Quote from: Fiyasko on January 13, 2012, 06:46:27 PM

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

Fiyasko

legendary

Activity: 1428

Merit: 1001

Okey Dokey Lokey

Quote from: ?? on ??

Quote from: Fiyasko on January 13, 2012, 06:46:27 PM

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

legendary

Activity: 1428

Merit: 1001

Okey Dokey Lokey

Quote from: ?? on ??

Quote from: Fiyasko on January 13, 2012, 02:10:21 PM

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://bitcointalksearch.org/topic/m.651989 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?

deepceleron

legendary

Activity: 1512

Merit: 1036

Quote from: antares on January 13, 2012, 03:21:26 PM

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.

antares

hero member

Activity: 518

Merit: 500

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

jake262144

full member

Activity: 210

Merit: 100

Quote from: deepceleron on January 13, 2012, 01:57:42 PM

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.

Fiyasko

legendary

Activity: 1428

Merit: 1001

Okey Dokey Lokey

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

deepceleron

legendary

Activity: 1512

Merit: 1036

Quote from: jake262144 on January 12, 2012, 06:22:22 PM

Quote from: grue on January 08, 2012, 11:16:34 PM

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.

jake262144

full member

Activity: 210

Merit: 100

Quote from: grue on January 08, 2012, 11:16:34 PM

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.

Fiyasko

legendary

Activity: 1428

Merit: 1001

Okey Dokey Lokey

Quote from: ?? on ??

https://bitcointalksearch.org/topic/official-cgminer-mining-software-thread-for-linuxwinosxmipsarmr-pi-4110-28402

ooouuu

Fiyasko

legendary

Activity: 1428

Merit: 1001

Okey Dokey Lokey

yeah i did see them

Fiyasko

legendary

Activity: 1428

Merit: 1001

Okey Dokey Lokey

Quote from: grue on January 08, 2012, 11:16:34 PM

Quote from: Fiyasko on January 05, 2012, 08:44:09 PM

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

Quote

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 Grin

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

grue

legendary

Activity: 2058

Merit: 1452

Quote from: Fiyasko on January 05, 2012, 08:44:09 PM

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

Quote

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 Grin

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

Fiyasko

legendary

Activity: 1428

Merit: 1001

Okey Dokey Lokey

Quote from: deepceleron on January 06, 2012, 01:42:12 AM

Quote from: Fiyasko on January 05, 2012, 04:38:12 PM

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

Topic: catalyst 12.1 Im flipping tables over it (Read 3291 times)