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

[Diapolo]

Can you make another version that includes all the recent changes and __init__.py does not need to changed?
thanks

Why?  Just unzip in the kernels/phatk/ directory.

Main reason is some people like to use this kernel with poclbm. The 7-11 works, but the newest doesn't because it requires changes in __init__.py which is specific to phoenix. BOARBEAR is asking for a version that includes all the additional improvements since 7-11 that doesn't require any changes to __init__.py.

It is impossible to create a version of this kernel that works without modifications in the main miner software. As I wrote, there are values and variables, that the kernel uses and which are precalculated in the miner software and then passed as parameters to the kernel. A miner, which doesn't pass the required parameters will not work without beeing modified, sorry.

You guys are free to mod the kernel for yourself to revert the changes, which require a modded miner software and only take the ones, which can work without.

Dia

what I meant was, excluding the changes that needs the modification of __init__.py can you release a version that has all the other changes?

What I do here is just hobby and I don't want it to take even more time, I hope you understand that. I can't maintain 2 different kernel versions, sorry.

Dia

[1714168108]

1714168108

[1714168108]

1714168108

[burningrave101]

Can you make another version that includes all the recent changes and __init__.py does not need to changed?
thanks

Why?  Just unzip in the kernels/phatk/ directory.

Main reason is some people like to use this kernel with poclbm. The 7-11 works, but the newest doesn't because it requires changes in __init__.py which is specific to phoenix. BOARBEAR is asking for a version that includes all the additional improvements since 7-11 that doesn't require any changes to __init__.py.

It is impossible to create a version of this kernel that works without modifications in the main miner software. As I wrote, there are values and variables, that the kernel uses and which are precalculated in the miner software and then passed as parameters to the kernel. A miner, which doesn't pass the required parameters will not work without beeing modified, sorry.

You guys are free to mod the kernel for yourself to revert the changes, which require a modded miner software and only take the ones, which can work without.

Dia

what I meant was, excluding the changes that needs the modification of __init__.py can you release a version that has all the other changes?

Unless you have a good reason for needing to use Poclbm over Phoenix, which I can't currently think of one, then there's no point in running Poclbm over Phoenix when Phoenix is faster.

[hugolp]

Unless you have a good reason for needing to use Poclbm over Phoenix, which I can't currently think of one, then there's no point in running Poclbm over Phoenix when Phoenix is faster.

Backup pools. Its a big plus (and peace of mind).

Also, for me poclmb is slightly faster than phoenix with the same kernel.

[burningrave101]

Unless you have a good reason for needing to use Poclbm over Phoenix, which I can't currently think of one, then there's no point in running Poclbm over Phoenix when Phoenix is faster.

Backup pools. Its a big plus (and peace of mind).

Also, for me poclmb is slightly faster than phoenix with the same kernel.

Can't you just create another Phoenix miner on a different pool with a low aggression value and it will take over if your main pool worker goes idle?

[hugolp]

Unless you have a good reason for needing to use Poclbm over Phoenix, which I can't currently think of one, then there's no point in running Poclbm over Phoenix when Phoenix is faster.

Backup pools. Its a big plus (and peace of mind).

Also, for me poclmb is slightly faster than phoenix with the same kernel.

Can't you just create another Phoenix miner on a different pool with a low aggression value and it will take over if your main pool worker goes idle?

I tried this (I was a phoenix user until poclbm added backup pools), but the second miner would take some hashing power from the main one (big deal), and then if the main one went down it would not perform at full speed because the aggression was lower.

[coblee]

Can't you just create another Phoenix miner on a different pool with a low aggression value and it will take over if your main pool worker goes idle?

That's really not the same. It's also more hassle. I use poclbm b/c it's just as fast as phoenix has better display and has backup pool.

[cyberlync]

To above posters, AOCLBF with Phoenix will solve your backup pool problems.

edit: Forgot about the linux peeps, just shows how much of a WinBlows nab I am. Pardon me good folks.

[coblee]

To above posters, AOCLBF with Phoenix will solve your backup pool problems.

But I'm using linux.

[ed64]

Latest poclbm from github made some tasks asynchronous and should bring it up to par with phoenix now as well.

Can't you just create another Phoenix miner on a different pool with a low aggression value and it will take over if your main pool worker goes idle?

That's really not the same. It's also more hassle. I use poclbm b/c it's just as fast as phoenix has better display and has backup pool.

[hugolp]

To above posters, AOCLBF with Phoenix will solve your backup pool problems.

But I'm using linux.

Im using linux too and dont want a GUI. I manage my mining rig through ssh.

[KKAtan]

here the files with these changes:
http://www.filesonic.com/file/1423103594

Thank you so much Vince. Your patch gives very nice performance for the HD 6870 cards I have, I sent a little something your way too.

Keep up the the good work guys, you are awesome.

[MegaBux]

I am running a 4x6770 rig, with all cards manufactured by Sapphire.  Also using Phoenix 1.5 with SDK 2.4 and 11.6 Catalyst drivers.  Each GPU is clocked to 960/800 at the stock voltage.

Prior to the patch, each GPU capped at 217Mhps.  This is with the 3% phatk mod.  After the patch, I saw no difference until I reduced the memory clock to 300Mhz.  The GPUs now cap at about 220Mhps.

I am wondering though if this is an accurate throughput measurement.  My pool is reporting lower-than-expected 24-rewards, and GPU temperatures are also 2 degrees cooler in this configuration.  I am also under the impression that 800Mhz is the lowest supported memory clock for this card.

Anyone else experience this phenomenon?

[MegaBux]

I am wondering though if this is an accurate throughput measurement.  My pool is reporting lower-than-expected 24-rewards, and GPU temperatures are also 2 degrees cooler in this configuration.  I am also under the impression that 800Mhz is the lowest supported memory clock for this card.

Anyone else experience this phenomenon?

I just realized that the difficulty went up during the time I was testing; this explains the lower 24h rewards.  I'm still curious as to how a lower memory clock frequency could improve the hash rate though.

[bmgjet]

lower heat, less power for sure
Also possible it does something with the timings.

[Dubs420]

Sent you a little donation as thanks for your work.

[Diapolo]

Reposted 2011-07-17 version because of a small mistake in variable naming. T1substate0 was wrong, it has to be state0subT1.
No further changes, that will do anything for those, who grabbed the version before this posting!

Currently no news for you guys, perhaps I can do a special version for 69XX cards (which could be 1 - 2 ALU OPs faster, but slower for 58XX), when there is demand. But for 58XX cards I'm out of optimisation ideas .

Dia

[MiningBuddy]

perhaps I can do a special version for 69XX cards (which could be 1 - 2 ALU OPs faster, but slower for 58XX)

Yes, please do! 

[xcooling]

69xx version would be wonderful ;-P

[deepceleron]

I think I jumped the gun.  I believe I am having a real hardware problem.  It's only on one card, the hotter one of the group, and it's overclocked and over-volted to all hell.  I think what happened is that these errors were hidden from the console until this new kernel update!  If that's the case, kudos for making the errors work! haha.

Not necessarely. I had the same problem with a card in previous versions of the kernel. After 20 minutes it would produce that message in phoenix or would crash poclbm. But with exactly the same configuration and later kernels it was solved, even when it was producing higher hashing rates. I am not sure why it happens exactly.

The code that creates this error is in the phatk init file:

                    if not hash.endswith('\x00\x00\x00\x00'):
                        self.interface.error('Unusual behavior from OpenCL. '
                            'Hardware problem?')

The error is reported if the hash returned by OpenCL does not begin with zeros. The error means that the hash-checking done in OpenCL thought the hash was valid and returned it, but this simple sanity check showed it was invalid. Either the hash-checking math was done wrong in OpenCL (saying that a bad hash was good, and perhaps silently discarding good hashes), or the correct hash is being corrupted when it is returned back to phatk core. It seems like something about the 07-17 kernel causes more errors on high overclock cards (perhaps running a different shader instruction that in silicon that is less tolerant to overclock?), errors that were not produced before at the same clock speed, which reduces overclockability.

[Diapolo]

69xx version would be wonderful ;-P

To all 69XX card owners, that want 1 ALU OP less, down to 1697 . Just edit the kernel.cl file and replace Line 385 (DL the latest 2011-07-17 version):

Vals[7] += Vals[3] + P4(124) + P3(124) + P2(124) + P1(124) + s1(124) + ch(124);

with

Vals[7] = Vals[7] + Vals[3] + P4(124) + P3(124) + P2(124) + P1(124) + s1(124) + ch(124);

Please report if it works . Remember, this WILL be slower for 58XX owners, so don't try this, if you are on 58XX cards or even (s)lower!

Dia