[ANN][GRS][DMD][DGB] Pallas optimized groestl opencl kernels

[pallas]

"when Pallas says that R9 280x is 18MH/s he counts it in Groestl hashes."

no my hashrates are taken from sgminer.

[pallas]

@pallas: Thanks for fiddling with Win7! What does it means by 32 bit code? That has no meaning regarding the GCN hardware o.O
But I'm 100% sure that you can't use my Capeverde binary unless you have that chip in the device you selected. ( var dev:=cl.devices[CLdeviceIndex]; )

Bins generated by sgminer on a 32 bit system will not work on a 64 bit one and viceversa, so I suppose the same is true for your kernels.

[sp_]

@pallas: Thanks for fiddling with Win7! What does it means by 32 bit code? That has no meaning regarding the GCN hardware o.O
But I'm 100% sure that you can't use my Capeverde binary unless you have that chip in the device you selected. ( var dev:=cl.devices[CLdeviceIndex]; )

Bins generated by sgminer on a 32 bit system will not work on a 64 bit one and viceversa, so I suppose the same is true for your kernels.

On linux yes, but on windows they work. You need to run the x86 build of sgminer.

[pallas]

@pallas: Thanks for fiddling with Win7! What does it means by 32 bit code? That has no meaning regarding the GCN hardware o.O
But I'm 100% sure that you can't use my Capeverde binary unless you have that chip in the device you selected. ( var dev:=cl.devices[CLdeviceIndex]; )

Bins generated by sgminer on a 32 bit system will not work on a 64 bit one and viceversa, so I suppose the same is true for your kernels.

infact:

[10:25:27] Internal error: Input OpenCL binary is not for the target!

[pallas]

@pallas: Thanks for fiddling with Win7! What does it means by 32 bit code? That has no meaning regarding the GCN hardware o.O
But I'm 100% sure that you can't use my Capeverde binary unless you have that chip in the device you selected. ( var dev:=cl.devices[CLdeviceIndex]; )

Bins generated by sgminer on a 32 bit system will not work on a 64 bit one and viceversa, so I suppose the same is true for your kernels.

Min end in l4.bin ... am I 32 or 64 ... (win 7 x64)

4 * 8 (bits) = 32

it's the size of a long integer.
probably the sgminer build you are using is 32 bit.

[pallas]

@pallas: Thanks for fiddling with Win7! What does it means by 32 bit code? That has no meaning regarding the GCN hardware o.O
But I'm 100% sure that you can't use my Capeverde binary unless you have that chip in the device you selected. ( var dev:=cl.devices[CLdeviceIndex]; )

Bins generated by sgminer on a 32 bit system will not work on a 64 bit one and viceversa, so I suppose the same is true for your kernels.

Min end in l4.bin ... am I 32 or 64 ... (win 7 x64)

4 * 8 (bits) = 32

it's the size of a long integer.
probably the sgminer build you are using is 32 bit.

question is does hetpas use 32 or 64 bit ... I'd assume 32 bit since it runs ok on my sgminer ...
my sgminer is old 4.1.0 ...

so you main prob is needing hetpas src to run on linux ...

Probably realhet coded it for 32 bit; I don't know what changes, maybe the parameter passing part.
I hope realhet has time to look into this.
I also use version 4.1.
Hetpas can't run on linux: I'll try again with the new version when I can access my workstation and make it boot on windows.

[JuanHungLo]

I built my bins with Wolf0's x64 miner.  Works perfectly.

[pallas]

I built my bins with Wolf0's x64 miner.  Works perfectly.

could you share your bin files please?

[JuanHungLo]

I built my bins with Wolf0's x64 miner.  Works perfectly.

could you share your bin files please?

Personally, I wouldn't download this.  I'd generate my own.  But here it is.  Use at your own risk!
http://ge.tt/2uga0R82/v/0?c

[pallas]

I built my bins with Wolf0's x64 miner.  Works perfectly.

could you share your bin files please?

Personally, I wouldn't download this.  I'd generate my own.  But here it is.  Use at your own risk!
http://ge.tt/2uga0R82/v/0?c

Thanks, but it's 32 bit, I need 64 bit.

[pallas]

HOW TO TELL IF AN SGMINER BIN FILE IS 32 OR 64 BIT

If the filename, generated by sgminer, ends in l4.bin it is 32 bit (8 x 4 = 32)
If the filename, generated by sgminer, ends in l8.bin it is 64 bit (8 x 8 = 64)

They are incompatible.

[Star65]

Guys! We do not need more optimization! If all we get a faster kernel, then the difficulty will increase proportionally. Accordingly, we will not get more coins, but will pay more for electricity. Profits will only decrease. 
Faster kernel good for dev only (as a reward for their hard work), i think so.

[pallas]

Guys! We do not need more optimization! If all we get a faster kernel, then the difficulty will increase proportionally. Accordingly, we will not get more coins, but will pay more for electricity. Profits will only decrease. 
Faster kernel good for dev only (as a reward for their hard work), i think so.

true....
until you have half the hashpower by a couple fpga miners (or so they say) ;-)

[utahjohn]

Guys! We do not need more optimization! If all we get a faster kernel, then the difficulty will increase proportionally. Accordingly, we will not get more coins, but will pay more for electricity. Profits will only decrease.  
Faster kernel good for dev only (as a reward for their hard work), i think so.

Not everyone will use new kernel so there is an advantage.  Yes diff will go up some.  Also as diff goes up many miners will drop like dead flies, so It will even out ...
Tell all your friends to Cloudmine/Multipool mine  and stop direct mining, this will lower diff for diehard solo miners

3 blocks DMD since I started ASM kernel last night ...

[pallas]

@Pallas
It is extremely rare for me to see any orphan when solo mining so I would venture to guess your network is too slow.

probably too few nodes nearby: I have 20/30 msec round trip time to big internet nodes in my country.
having few fast nodes nearby means my blocks take a lot of time to spread thru the diamond network.
or a lot of bad luck

[qwep1]

Target: Tahiti  Series: 7  Core:1100 MHz  CU:32  RAM:3072 MB  UID:4098
ext: cl_khr_fp64 cl_amd_fp64 cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_int64_base_atomics cl_khr_int64_extended_atomics cl_khr_3d_image_writes cl_khr_byte_addressable_store cl_khr_gl_sharing cl_ext_atomic_counters_32 cl_amd_device_attribute_query cl_amd_vec3 cl_amd_printf cl_amd_media_ops cl_amd_media_ops2 cl_amd_popcnt cl_khr_d3d10_sharing cl_khr_d3d11_sharing cl_khr_dx9_media_sharing cl_khr_image2d_from_buffer cl_khr_spir cl_khr_gl_event
* core MHz value is not always accurate, use Catalyst Control Center (ADL) instead!

elapsed: 69.778 ms  37.568 MH/s   gain:   9.39x
elapsed: 54.247 ms  48.324 MH/s   gain:  12.08x
elapsed: 54.269 ms  48.305 MH/s   gain:  12.08x
elapsed: 54.236 ms  48.334 MH/s   gain:  12.08x
############### RESULT IS WRONG ###################
   idx        hi       lo           hi           lo
     0: 00000000 00000000            0            0
     1: 00000000 00000000            0            0
     2: 00000000 00000000            0            0
     3: 00000000 00000000            0            0
     4: 00000000 00000000            0            0
     5: 00000000 00000000            0            0
     6: 00000000 00000000            0            0
     7: 00000000 00000000            0            0
     8: 00000000 00000000            0            0
     9: 00000000 00000000            0            0
     A: 00000000 00000000            0            0
     B: 00000000 00000000            0            0
     C: 00000000 00000000            0            0
     D: 00000000 00000000            0            0
     E: 00000000 00000000            0            0
     F: 00000000 00000000            0            0
    10: A9A41A9D 9337706F  -1448863075  -1825083281
    11: 370D1AF4 DD743586    923605748   -579586682
    12: CB7EB389 EADF9917   -880888951   -354445033
    13: 25FA6A42 76EDCD1E    637168194   1995296030
    14: 91783455 C7EE8F10  -1854393259   -940667120
    15: F60C362A FD9AFAB3   -166971862    -40174925
    16: 038C0C0F D2E4564F     59509775   -756787633
    17: EA28DD29 3A1B41CA   -366420695    974864842
    18: 708C1E9A DFCDC04F   1888231066   -540164017
    19: 00000000 A7B76679            0  -1481152903
    1A: 00000000 00000000            0            0
    1B: 00000000 00000000            0            0
    1C: 00000000 00000000            0            0
    1D: 00000000 00000000            0            0
    1E: 00000000 00000000            0            0
    1F: 00000000 00000000            0            0
this is normal or am I doing something wrong

do not get me compile a file

[physixz]

Whats the best driver version to use as i can only get 11MH/s from my R9 290

[pallas]

Whats the best driver version to use as i can only get 11MH/s from my R9 290

14.6b or 14.7

Or use the precompiled binary.

[qwep1]

where there is a folder kernel_dump\  ???I can not find

[utahjohn]

@realhet
OK a few things I have discovered:
1. Hetpas does compile and run ok on 14.7RC3.
    So no need to install 14.9
2. Test Runs:
Target: Tahiti  core:1150 MHz  cu:32  ram:3072 MB  uid:4098
ext: cl_khr_fp64 cl_amd_fp64 cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_int64_base_atomics cl_khr_int64_extended_atomics cl_khr_3d_image_writes cl_khr_byte_addressable_store cl_khr_gl_sharing cl_ext_atomic_counters_32 cl_amd_device_attribute_query cl_amd_vec3 cl_amd_printf cl_amd_media_ops cl_amd_media_ops2 cl_amd_popcnt cl_khr_d3d10_sharing cl_khr_d3d11_sharing cl_khr_dx9_media_sharing cl_khr_image2d_from_buffer cl_khr_spir cl_khr_gl_event
* core MHz value is not always accurate, use Catalyst Control Center (or ADL) instead!

Using original OpenCL code
Kernel binary saved: C:\Miners\HetPas150111_Groestl\groestl\kernel_dump\kernel.elf

elapsed: 72.626 ms  36.095 MH/s   gain:   9.02x
elapsed: 70.712 ms  37.072 MH/s   gain:   9.27x
elapsed: 70.718 ms  37.069 MH/s   gain:   9.27x
elapsed: 70.741 ms  37.057 MH/s   gain:   9.26x

Functional test: RESULT IS OK

Target: Tahiti  core:1150 MHz  cu:32  ram:3072 MB  uid:4098
ext: cl_khr_fp64 cl_amd_fp64 cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_int64_base_atomics cl_khr_int64_extended_atomics cl_khr_3d_image_writes cl_khr_byte_addressable_store cl_khr_gl_sharing cl_ext_atomic_counters_32 cl_amd_device_attribute_query cl_amd_vec3 cl_amd_printf cl_amd_media_ops cl_amd_media_ops2 cl_amd_popcnt cl_khr_d3d10_sharing cl_khr_d3d11_sharing cl_khr_dx9_media_sharing cl_khr_image2d_from_buffer cl_khr_spir cl_khr_gl_event
* core MHz value is not always accurate, use Catalyst Control Center (or ADL) instead!

Using new GCN ASM code
Kernel binary saved: C:\Miners\HetPas150111_Groestl\groestl\kernel_dump\kernel.elf

elapsed: 53.629 ms  48.881 MH/s   gain:  12.22x
elapsed: 50.666 ms  51.740 MH/s   gain:  12.93x
elapsed: 50.677 ms  51.729 MH/s   gain:  12.93x
elapsed: 50.660 ms  51.746 MH/s   gain:  12.94x

Functional test: RESULT IS OK

3. Calculated speed gain is close to actual speed gain of 1.40x as shown running sgminer

4. First run of OCL should be reference value of 1.0x to do proper comparison, this needs to be reset in hetpas for each architecture.

5. Your timing calculations appear to be wrong.  Single 280x OCL is 18.5MHs, Single 280x ASM is 26.0MHs.
    Are you sure hetpas is not using BOTH of the cards in my test box when running tests?  I am mining in sgminer with SINGLE card, other is turned off and used in another instance of sgminer mining neoscrypt ...