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

[petala]

Any news about 7970 support as that card is quite good at 666 mhash/s and $550 right now ?

cheers !

[1714822824]

1714822824

[Diapolo]

Any news about 7970 support as that card is quite good at 666 mhash/s and $550 right now ?

cheers !

Currently I have none and the AMD KernelAnalyzer seems to currently not support GCN architecture, so it's hard to do any optimizsations for it. But I would be interested in results with 7970 and my kernel (new kernel is on it's way to release). AMD sais, that massive vectorisation would not be needed for optimal performance with GCN, so perhaps it would run well without the use of a VECTORSn parameter.

Dia

[Diapolo]

A new version is ready for your testing pleasure:
Download version 2012-01-13: http://www.mediafire.com/download.php?2sqoj8obvp1q23p

highlights:
- the child has it's name, I call it phatk_dia - would be nice if you guys use this in discussions to be clear what your kernel is
- faster on VLIW5 GPUs with VECTORS2 and VECTORS4
- more efficient on VLIW4 GPUs with VECTORS2 and a little faster with VECTORS4
- FASTLOOP defaults to false, so you don't need to supply FASTLOOP=false
- added an extended check for supplied WORKSIZE parameter
- removed a pyOpenCL finish() to reduce API overhead (could cause problems, but works here -> consider this beta till it proves stable)

Please report and give me all your coins :-D!

Edit: Please don't complain if this doesn't work good for non 2.6 SDK / Runtime versions, because this IS for 2.6 or later!

Dia

[SocialBonobo]

A new version is ready for your testing pleasure:
Download version 2012-01-13: http://www.mediafire.com/download.php?2sqoj8obvp1q23p

Do you provide a git repository of this fork?

[Diapolo]

A new version is ready for your testing pleasure:
Download version 2012-01-13: http://www.mediafire.com/download.php?2sqoj8obvp1q23p

Do you provide a git repository of this fork?

Sorry, but no ... I use Beyond Compare 3 for editting / comparing the files and manage the rest in my brain . Guess that's kind of old school, but it works.
To be honest, I don't even know how to use a git repository.

Dia

[Diapolo]

Uploaded a fixed version, which corrects an error with FASTLOOP=True:
Download version 2012-01-13: http://www.mediafire.com/?xzk6b1yvb24r4dg

There are no other changes in this version!

Dia

[Diapolo]

Uploaded a fixed version, which corrects an error with FASTLOOP=True:
Download version 2012-01-13: http://www.mediafire.com/?xzk6b1yvb24r4dg

There are no other changes in this version!

Dia

I no longer see the mhash/s. also I don't see the shares and other statistics.(basically the entire button line)

I do see the log which says at which time a share was accepted and that says other things.

That's not a helpful bug report ... sorry. What OS? Can you paste an output of the Phoenix window.
What's your command line? Was this introduced with the FASTLOOP fix or before?

Dia

[Diapolo]

The part with the stats you mention is blinking for me too, this seems to happen with high aggression and when it updates to new values.
You should try the latest version with the latest Phoenix 1.7.3 and it would be great to get some speed reports in here.

I have to say I'm a bit disappointed at least with the feedback to this release, not to mention simply nothing is coming in ... even if this version is NOT faster for some, it took many hours to do it and it's not satisfying that way. For me the current version IS faster than phatk2 with 6550D and the difference is huge, I don't understand why this seems to be not the case for any other user here. Guys please use 12.1a with Phoenix 1.7.3 and the settings mentioned on page 1 in this thread. If you complain that it's not faster only do this with some system infos like SDK, OS, driver, card, Phoenix version and used command switches, thank you!

Edit: You can also post the contents of the Phoenix window here.

Code:

[14/01/2012 14:43:18] using PyOpenCL version 0.92
[14/01/2012 14:43:18] checked nonces per kernel execution: 67108864
[14/01/2012 14:43:18] using VECTORS2, resulting global worksize is: 33554432
[14/01/2012 14:43:18] using local worksize of 128 (HW max. is 256)
[14/01/2012 14:43:18] cl_amd_media_ops ext. found - BFI_INT enabled

[14/01/2012 14:43:19] Finding inner ELF...
[14/01/2012 14:43:19] Patching inner ELF...
[14/01/2012 14:43:19] Patching instructions...
[14/01/2012 14:43:19] BFI-patched 472 instructions...
[14/01/2012 14:43:19] Patch complete, returning to kernel...
[14/01/2012 14:43:19] Applied BFI_INT patch
[14/01/2012 14:43:19] Phoenix v1.7.3 starting...
[14/01/2012 14:43:19] Connected to server
[14/01/2012 14:43:19] Server gave new work; passing to WorkQueue
[14/01/2012 14:43:19] New block (WorkQueue)
[14/01/2012 14:43:21] Server gave new work; passing to WorkQueue
[66.19 Mhash/sec] [0 Accepted] [0 Rejected] [RPC (+LP)]

Dia :-/

[deepceleron]

its cause of the aggresion at 16, when I put it on 15 it shows again but the miner is idle a lot according to the log and the khash/s are at 0 however its still mining and getting hashes accepted.
with 14 its working fine but slightly lower mhash/s then with the older one kernel at aggression 17. (417 compared to 418 mhash/s.)

This is because above 12 or 13 is insane aggression - the miner hogs the GPU so much that the Windows GUI can't even draw stuff like the status line on the screen.

[deepceleron]

its cause of the aggresion at 16, when I put it on 15 it shows again but the miner is idle a lot according to the log and the khash/s are at 0 however its still mining and getting hashes accepted.
with 14 its working fine but slightly lower mhash/s then with the older one kernel at aggression 17. (417 compared to 418 mhash/s.)

This is because above 12 or 13 is insane aggression - the miner hogs the GPU so much that the Windows GUI can't even draw stuff like the status line on the screen.

It was fine with the older kernel.
Does that mean anything?
I think this kernel is slightly faster then the older one.

It is possible that the previous kernel and miner parameters didn't work the GPU so hard; as kernels are optimized, they use more of the GPU resources available, approaching 100%, leaving less chance that OS draw instructions will make it through in a timely fashion.

[Diapolo]

Just a hint, this kernel is for SDK 2.6+, it doesn't work well with earlier versions / runtimes!

Dia