Author

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

legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
I am presuming you are talking about the .CL code ... coz it's not entirely clear ...

With cgminer all you have to do is change is the .CL file (then delete a file) and nothing more if you are dealing with that side of things ...
Replace one .CL file with a new one (or edit it) and delete the .bin and that's it.

Next time you start cgminer it will compile the new .CL internally and generate a .bin and run that in the GPU
So after editing the .CL, the hardest step (of only 2 required) is to delete a .bin file Tongue
(the other step is to run cgminer ... though that can be difficult for some also ...)
hero member
Activity: 772
Merit: 500
It's most unusual that you work with only phoenix... it's not like working with cgminer is hard.

I like the fact, that with Phoenix I don't have to fiddle around with a compiler, headers, paths and so on. I can edit a plain text file to change things I need for initialisation (even if I dislike Python ^^) and simply start phoenix.exe without recompiling after every small change + I can redistribute my changes without the need for a new executable.

In no way I want to say Phoenix is better or worse than CGMINER (I know you work hard and do a great job), but for the things I do it's easier for me to use Phoenix Wink.

Dia
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
Ah.  Gotcha.  I'll give it another go.Well, in that case, there's another thing to sort out that doesn't make any damn sense (of course).  The phatk kernel doesn't always run on GPU0.  It's fairly random.  It always runs on the other 3 cards every time.  CGMiner pauses with a message about closing other apps that use the GPU (like Afterburner).  If I close CGMiner and restart it with the same command line, it'll run.  It's probably 50/50.  
Yes this is the never ending mindfuck that is windows creating a binary that reports size zero after it's built. Then it changes its mind and works the next time around. It's a bug that's plagued cgminer on windows for 6 months now and makes no sense whatsoever to anyone.
Uploaded a fresh .exe which may fix this problem. It turns out I may have been attempting to build the opencl program twice.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
Further investigation reveals the phatk kernel included with the current cgminer basically ONLY works with the  bfi int patching. That means the kernel itself needs fixing to even work in its current intended form, so there's still some work to go... However for those brave, at least you have an exe you can use with the kernel and you can delete the .bin files and manually fiddle with the code in the phatk*.cl file included. Other kernels taken from other projects diablo, diapolo, phoenix etc will NOT under ANY circumstances work directly as the API is different so don't waste your time trying that.
I've upgrade a *potential* fix for the phatk kernel in here:
http://ck.kolivas.org/apps/cgminer/temp
Make sure to right click on phatk110817.cl and choose save link as to avoid your browser turning into html falsely. 79x0 Try replacing the file with that one with the new exe and see if that submits valid shares...
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
Further investigation reveals the phatk kernel included with the current cgminer basically ONLY works with the  bfi int patching. That means the kernel itself needs fixing to even work in its current intended form, so there's still some work to go... However for those brave, at least you have an exe you can use with the kernel and you can delete the .bin files and manually fiddle with the code in the phatk*.cl file included. Other kernels taken from other projects diablo, diapolo, phoenix etc will NOT under ANY circumstances work directly as the API is different so don't waste your time trying that.

My current posted kernel version doesn't work with 7970, but I'm currently in the process of rewriting / reordering the kernel, which currently gives a performance of ~540 MHash/s for my 7970 card (this was over 100 MHash/s lower before I started my work). I guess there is still more potential in it, DiabloD3s kernel seems to be even faster! But as Con said, this won't work for CGMINER ...

Dia
It's most unusual that you work with only phoenix... it's not like working with cgminer is hard.
hero member
Activity: 772
Merit: 500
Further investigation reveals the phatk kernel included with the current cgminer basically ONLY works with the  bfi int patching. That means the kernel itself needs fixing to even work in its current intended form, so there's still some work to go... However for those brave, at least you have an exe you can use with the kernel and you can delete the .bin files and manually fiddle with the code in the phatk*.cl file included. Other kernels taken from other projects diablo, diapolo, phoenix etc will NOT under ANY circumstances work directly as the API is different so don't waste your time trying that.

My current posted kernel version doesn't work with 7970, but I'm currently in the process of rewriting / reordering the kernel, which currently gives a performance of ~540 MHash/s for my 7970 card (this was over 100 MHash/s lower before I started my work). I guess there is still more potential in it, DiabloD3s kernel seems to be even faster! But as Con said, this won't work for CGMINER ...

Dia
legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
Further investigation reveals the phatk kernel included with the current cgminer basically ONLY works with the  bfi int patching. That means the kernel itself needs fixing to even work in its current intended form, so there's still some work to go... However for those brave, at least you have an exe you can use with the kernel and you can delete the .bin files and manually fiddle with the code in the phatk*.cl file included. Other kernels taken from other projects diablo, diapolo, phoenix etc will NOT under ANY circumstances work directly as the API is different so don't waste your time trying that.
... and of course if anyone was confused about the domain of that statement - it is of course only referring to the new 7970 cards Smiley
Nothing else.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
Further investigation reveals the phatk kernel included with the current cgminer basically ONLY works with the  bfi int patching. That means the kernel itself needs fixing to even work in its current intended form, so there's still some work to go... However for those brave, at least you have an exe you can use with the kernel and you can delete the .bin files and manually fiddle with the code in the phatk*.cl file included. Other kernels taken from other projects diablo, diapolo, phoenix etc will NOT under ANY circumstances work directly as the API is different so don't waste your time trying that.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
Ah.  Gotcha.  I'll give it another go.Well, in that case, there's another thing to sort out that doesn't make any damn sense (of course).  The phatk kernel doesn't always run on GPU0.  It's fairly random.  It always runs on the other 3 cards every time.  CGMiner pauses with a message about closing other apps that use the GPU (like Afterburner).  If I close CGMiner and restart it with the same command line, it'll run.  It's probably 50/50.  
Yes this is the never ending mindfuck that is windows creating a binary that reports size zero after it's built. Then it changes its mind and works the next time around. It's a bug that's plagued cgminer on windows for 6 months now and makes no sense whatsoever to anyone.
hero member
Activity: 642
Merit: 500
Starting CGMiner with 14 intensity (with poclbm) causes all of the cards to start at just above 500Mhash/sec and slowly creep down to around 420Mhash.  It seems to have no effect when using the phatk kernel.
hero member
Activity: 642
Merit: 500
Ah.  Gotcha.  I'll give it another go.

I see.  I just assumed if a GPU wasn't at full utilization, a 2nd thread would be able to chew up the unused cycles.  I've never written anything for OpenCL though, so I certainly don't claim to fully understand it.

Well, in that case, there's another thing to sort out that doesn't make any damn sense (of course).  The phatk kernel doesn't always run on GPU0.  It's fairly random.  It always runs on the other 3 cards every time.  CGMiner pauses with a message about closing other apps that use the GPU (like Afterburner).  If I close CGMiner and restart it with the same command line, it'll run.  It's probably 50/50.  The poclbcm kernel seems to always compile/run.

Also, all shares created with the phatk kernel are invalid and just get marked as hardware errors.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
Thanks. By the way, I reuploaded the exe after that first message so perhaps you got the dud build. Please try re-downloading it.

Increasing threads is nothing like increasing intensity so it will not have the same effect.

Finally, we are never going to get there with the poclbm kernel. The one it is loading is ancient and numerous improvements have happened since then, most of which are in the phatk kernel. Unless I can get the existing phatk kernel working it's going to be nigh on useless trying to mine on 79x0 until I can create an entirely new kernel...
hero member
Activity: 642
Merit: 500
Unrelated -- I tried to compile cgminer in Windows last night.  You weren't kidding.  Pain in the ass.  I finally got everything to configure and almost everything complied, and then I ran into some screwy incompatibilities between the Windows SDK Winsock includes and the Winsock includes supplied by MinGW.  It was a brutal night.  Props for getting the thing to run in Windows in the first place without a substantial rewrite.  Smiley
hero member
Activity: 642
Merit: 500
I tried running with --no-adl and there was little to no change.  Bah.  I thought that would be it.
hero member
Activity: 642
Merit: 500
Interesting. Redownload the .exe, I've made a few minor changes and now you can increase intensity to 14. The other thing to try is increase the threads from 2 to 3 or more with -g 3

Increasing the thread count to 3 definitely smooths out the hashrate, but it doesn't increase it.

I just thought of something else.  I haven't seen anyone else mention it yet, but I noticed when I'm using Diablominer and I run Afterburner, my hash rate slows down dramatically until I close it.  It's like the hardware polling that Afterburner does actually interrupts the GPU.  Is there a way to turn off ADL polling?  Edit:  Why yes -- there is.

Intensity still seemed to be capped at 10 on that binary (unless it lets you change it but doesn't show the change?)

If it were intensity related, I'm sure adding more threads would have cleared it up though.  Sad   Probably no need to recompile again to test it.

Another thing that is odd is the hash rate (not the long average) seems to increase very slowly with time before capping.  In other words, I run cgminer and get anywhere from 400 to 430 per card.  Once I let it run for a good 5 minutes or so, they eventually get up to around 460 and stop rising.  It takes ages to get there though.

Lastly, the GPUs tend to all hash at significantly different rates until cgminer has run for a long enough period of time.  There are 4 GPUs in this rig and they'll differ by 10 percent or so between cards until it has run a while.
legendary
Activity: 1876
Merit: 1000
I'm getting some pretty weird results.  Here is some food for thought.  Keep in mind I'm running these at 1075Mhz:

I get about 440 per GPU if I make sure to specify the poclbm kernel, --vectors 1, and a worksize of 256.  Here's the odd thing though -- the only way to get this is to have the intensity maxed at 10.  If I use 9, the hash rate drops by over 100Mhash/sec.

Here's where it gets even more weird.  If I move the mouse all over the place or move a window all over the place to make the GPU a little more busy, hashrate goes *up*.  I get about 495 per GPU and can get them to bump past 500 for short periods of time.

To top it off...?  After doing this, the hashrate doesn't go back down when I stop screwing with the GUI.  It stays steady.  There's some sort of throttling going on and I'm guessing CGMiner isn't keeping the cards busy enough.  Is it possible to make the intensity even more aggressive and see if this makes a difference?

How about trying more threads?  I haven't downloaded yet
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
Interesting. Redownload the .exe, I've made a few minor changes and now you can increase intensity to 14. The other thing to try is increase the threads from 2 to 3 or more with -g 3

oops hang on, intensity doesnt work yet, but try -g 3
Now it should work (redownload exe).
hero member
Activity: 642
Merit: 500
Also, I'm not sure why Roadhog isn't getting valid shares.  Mine are.
hero member
Activity: 642
Merit: 500
I'm getting some pretty weird results.  Here is some food for thought.  Keep in mind I'm running these at 1075Mhz:

I get about 440 per GPU if I make sure to specify the poclbm kernel, --vectors 1, and a worksize of 256.  Here's the odd thing though -- the only way to get this is to have the intensity maxed at 10.  If I use 9, the hash rate drops by over 100Mhash/sec.

Here's where it gets even more weird.  If I move the mouse all over the place or move a window all over the place to make the GPU a little more busy, hashrate goes *up*.  I get about 495 per GPU and can get them to bump past 500 for short periods of time.

To top it off...?  After doing this, the hashrate doesn't go back down when I stop screwing with the GUI.  It stays steady.  There's some sort of throttling going on and I'm guessing CGMiner isn't keeping the cards busy enough.  Is it possible to make the intensity even more aggressive and see if this makes a difference?
full member
Activity: 131
Merit: 100
Yeah, I downloaded the fresh 2.1.2 and unpacked it to its own directory. Then I just put the EXE in you posted. Any specific settings you want me to try?
Try combinations manually with other vectors and worksize, -v 1, -v 2, -v 4, -w 64 -w 128 , -w 256
But if it fails by default there's a good change it's simply broken for now.

Oh and start it with -D -T and post output please?

I tried the vectors, -v 2, and -v 4, result in <100mh/s speeds. -w doesn't seem to affect the speed any.

Here is -D -T
http://pastebin.com/pNYkeAHh
Jump to: