further improved phatk_dia kernel for Phoenix + SDK 2.6 - 2012-01-13

[Enterpol]

Thanks for this.  Only 3 more hashes/s on my 5830, but it allows me to clock it down about 5-10 mhz without losing hashes.  This leads to a more stable card!  Awesome! 

[1715567803]

1715567803

[1715567803]

1715567803

[jh1523]

You could try to add http:// in front of user / pass:

Code:

python phoenix.py -u http://user:pass@pool:8332 -k phatk DEVICE=0 VECTORS2 BFI_INT FASTLOOP=false AGGRESSION=12 WORKSIZE=128

Dia

Duh! That works, thanks! However it still doesn't work with BAMT's automatic mine scripts (but this isn't the kernel's problem).

Nonetheless I get 4Mhash/s less with the new kernel compared to the old one on a 5870 (466Mhash/s vs 470Mhash/s, all other things being equal except for using VECTORS2 with the new kernel).

[typhoon]

I can't wait to give this kernel a shot when I get home!

[cletus815]

This is great work and I can't believe I'm just finding it. Thanks!

[Diapolo]

Download version 2011-08-11: http://www.mediafire.com/?s5c7h4r91r4ad4j

New version for your testing pleasure . Remember to use VECTORS2 as switch!
This one should be a bit faster for 58XX and 69XX cards compared to earlier versions PLUS it should not generate invalid shares, if more than 1 positve nonce is found in a work-group!

If a few of you could make a comparison (with older or other kernel versions) of accepted shares over a certain period of time, this woule be pretty cool!

Dia

[jh1523]

So far my results are as follows (all other things being equal except for using VECTORS2 instead of VEC TORS on all kernels since 8/4/11):

kernel from SVN 7/25/11: 470MHash/s, approx 0.5% stale shares
Diapolo kernel 8/4/11: 466Mhash/s, didn't run long enough for % stales
Diapolo kernel 8/11/11: 467 Mhash/s, stale test in progress.

All of this is on a 5870.

On a 5850, same remarks as above:

SVN 7/25/11: 381Mhash/s, 0.5% avg stales
Diapolo 8/4/11: not tested
Diapolo 8/11/11: 381Mhash/s, stales in progress.

(edit) after 537 shares on the 5870 and 423 on the 5850, 0% stales on either.

(edit2) around share #580, the 5870 gave me a " Kernel error: Unusual behavior from OpenCL. Hardware problem?" but then continued mining.

(edit3) after 2 1/2 hours:
5870: 932 shares, 10 stales (1.06%)
5850: 758 shares, 14 stale (1.69%)

I am switching back to the kernel from 7/25; on my system I get better performance from it.

[Una]

Diapolo:
Have you tried using the APP Profiler for actual execution stats?
I've found it to be a much better way of comparing different kernel versions.
The method I've used is:

• Run it for a fixed period of time. Just a couple minutes is fine.
• Open up the csv output in a spreadsheet.
• Average the ALUBusy then the  ALUPacking columns.
• Convert the averages from percent to decimal (99.42 to .9942) and multiply them together.
• Multiply that number by the device SP count. (5770=800, 5870=1600, 6950=1400, 6970=1536, etc..)
• Divide by ALUInsts.

Now you have a number (for that specific device only) which paints a more complete picture of actual performance.
This also shows how (but not why) the last couple versions have performed slower on 69xx.
While the number of executed instructions have gone down, the overall SP utilization has also gone down.

-Una

[Diapolo]

Diapolo:
Have you tried using the APP Profiler for actual execution stats?
I've found it to be a much better way of comparing different kernel versions.
The method I've used is:

• Run it for a fixed period of time. Just a couple minutes is fine.
• Open up the csv output in a spreadsheet.
• Average the ALUBusy then the  ALUPacking columns.
• Convert the averages from percent to decimal (99.42 to .9942) and multiply them together.
• Multiply that number by the device SP count. (5770=800, 5870=1600, 6950=1400, 6970=1536, etc..)
• Divide by ALUInsts.

Now you have a number (for that specific device only) which paints a more complete picture of actual performance.
This also shows how (but not why) the last couple versions have performed slower on 69xx.
While the number of executed instructions have gone down, the overall SP utilization has also gone down.

-Una

Not yet, I had the impression that this only works for V++ non Express Editions!? I will take a look now .
Are you skilled to interpret APP Profiler results?

Dia

[mute20]

This worked very good got a bigger increase than overclocking 50 mhz which would crash my computer

[Una]

Not yet, I had the impression that this only works for V++ non Express Editions!? I will take a look now .
Are you skilled to interpret APP Profiler results?

Dia

I have no idea about the Windows version, but the Linux version works completely standalone.
I wouldn't say I'm skilled at all. It just happened to be bundled with the SDK, and seemed like it would be helpful.
I more or less just figured out what was important in the output and figured out a way to directly compare results.
Having actual runtime data seems like it would be more helpful than the projections the kernel analyzer gives you.

-Una

[JBDive]

NICE!

Dropped the new kernel into GUIMiner's sub folders, created a new Phoenix Miner with the default switch listed on page 1 and BAM a solid 10% increase if not a little more and so far stales are zero in the 20 minutes I have been running it using Bitcoins.LC pool.

I can't send much but I will certainly send something, will see how the pool goes over the next day and how well the new kernel holds up.

[Diapolo]

I did a short test with the latest kernel and it seems the ALUBusy value of 68,9% is way too low. Only 68% of GPU time is used for ALU instruction processing. The  ALUPacking of 98,5% is nearly ideal.

Dia

[tiberiandusk]

My 5870 went from 436 to 398.

[Diapolo]

My 5870 went from 436 to 398.

VECTORS2?

[jh1523]

As an addition to my post above, I have tried to test the new kernel in Windows as well, using guiminer/phoenix. When replacing the default kernel.cl and __init__.py with the ones from kernel 8/11/11 followed by creating a new miner I get the following:

Code:

2011-08-12 07:44:40: Running command: C:\guiminer-20110701\guiminer\phoenix.exe -u http://user:pass@pool:8332 PLATFORM=0 DEVICE=0 -k phatk BFI_INT  VECTORS2  FASTLOOP=false WORKLOAD=128 AGGRESSION=11
2011-08-12 07:44:40: Listener for "testdiapolo" started
2011-08-12 07:44:41: Listener for "testdiapolo": [12/08/2011 07:44:41] FATAL kernel error: Failed to load OpenCL kernel!

As a further test I put back the original kernel.cl and __init__.py, and the test miner works fine with them.

[tiberiandusk]

My 5870 went from 436 to 398.

VECTORS2?

Thanks, I knew I was missing something. I'm at 451 now.

[aeonf]

I have the exact same problem as jh1523 .

[lenguyenphat]

Is there any download link different than mediafire? Unable to download!

[rafuter]

Is it also possible to update the latest OpenCL driver, for example ATI SDK, before the program starts ?

Why dont you add such feauture before improving speeds ?

[Diapolo]

As an addition to my post above, I have tried to test the new kernel in Windows as well, using guiminer/phoenix. When replacing the default kernel.cl and __init__.py with the ones from kernel 8/11/11 followed by creating a new miner I get the following:

Code:

2011-08-12 07:44:40: Running command: C:\guiminer-20110701\guiminer\phoenix.exe -u http://user:pass@pool:8332 PLATFORM=0 DEVICE=0 -k phatk BFI_INT  VECTORS2  FASTLOOP=false WORKLOAD=128 AGGRESSION=11
2011-08-12 07:44:40: Listener for "testdiapolo" started
2011-08-12 07:44:41: Listener for "testdiapolo": [12/08/2011 07:44:41] FATAL kernel error: Failed to load OpenCL kernel!

As a further test I put back the original kernel.cl and __init__.py, and the test miner works fine with them.

What is WORKLOAD=128? This should be WORKSIZE=128!

Dia