[Cast XMR] high speed XMR/CryptoNight miner for RX Vega GPUs (2 KHash/s)

[Morgon]

Please make Linux version!

 No point at this time since AMD still has ZERO working drivers for Vega on LINUX.

Why are people still parroting this nonsense?  AMD absolutely has a Blockchain driver for Linux.

I don't believe it's as performant as the Windows drivers, but to say it doesn't exist is entirely incorrect.

Its integrated into the new drivers now.

You mean blockchain is integrated into the latest Radeon Production GA Release?

The blockchain driver has been integrated into the drivers for at least three revisions. The problem for Vega users is that while there is a dedicated 'Compute' switch for x70/x80 devices, AMD decided to make them 'automatic' for Vega GPUs. This autodetection does work for Ethereum workloads, but has not been fixed for Cryptonight.

[QuintLeo]

AMD has a blockchain driver for LINUX - but it DOES NOT WORK on the Vega, nor does ANY OTHER driver they currently have available for LINUX that supports OpenCL.
 Their non-PRO driver seems to work on Vega, but NOT AMDGPU-PRO which is needed for OpenCL and mining support.

 Widely reported, and verified on their own support web site.

 In THEORY, this could change at any time - but as of earlier tonight when I checked the primary thread on the subject, it had NOT changed.


 The LINUX 17.40 blockchain driver appears to work on RX 4xx/5xx series cards and possibly some of the older GCN cards, but fan control and clock control are VERY primitive at this point.



 On the windows side, Large Page support (which is most of what the Blockchain driver stuff was about) has been integrated into the "mainline" drivers since about 17.11, but has issues as mentioned.

[lipz]

Please help me for share command for control gpu/ram clock , voltage control of cast xmr to me
Thank a lot.

[dagarair]

Please make Linux version!

 No point at this time since AMD still has ZERO working drivers for Vega on LINUX.

Why are people still parroting this nonsense?  AMD absolutely has a Blockchain driver for Linux.

I don't believe it's as performant as the Windows drivers, but to say it doesn't exist is entirely incorrect.

Its integrated into the new drivers now.

You mean blockchain is integrated into the latest Radeon Production GA Release?

The blockchain driver has been integrated into the drivers for at least three revisions. The problem for Vega users is that while there is a dedicated 'Compute' switch for x70/x80 devices, AMD decided to make them 'automatic' for Vega GPUs. This autodetection does work for Ethereum workloads, but has not been fixed for Cryptonight.

Probably want to read what quint said FOR VEGA

[MickDaster]

How do Ardenalin drivers work if you use them on a setup that has rx570 rx 580 and Vega included?

Any expirience with that?

[Apneal]

Adrenaline drivers even without any additional cards besides Vega shows decrease in hashrate from 2k to about 1350 compared to blockchain beta drivers. Cast XMR warns that blockchain drivers aren't detected on launch.

My question is, if the 'compute' optimizations are already turned on in Adrenaline drivers for Vega, why does Cast XMR not perform similarly or detect that the drivers are 'compute' enabled?

[Morgon]

AMD has a blockchain driver for LINUX - but it DOES NOT WORK on the Vega, nor does ANY OTHER driver they currently have available for LINUX that supports OpenCL.

 Widely reported, and verified on their own support web site.

Both the Beta driver and this week's Radeon Software for Linux release specifically state that Vega is supported. Where are you seeing otherwise?

[glph3k]

Hi,

a new version is available:

Cast XMR Version 0.8 (2017/12/14)

  - kernel optimizations result in subtle performance improvements

  - --fastjobswitch option (experimental) to force fast switching to new jobs. When enabled the GPUs will switch to the new job within less then 100ms. This improves the effective hash rate by 1 to 5% as nearly no GPU performance will be wasted on calculating outdated shares anymore. The drawback is a slightly lower displayed hashrate as while switching no hashes are calculated.

  - improved support for more then 8 GPUs

  - support for Radeon RX 470/RX 570 (Polaris) added

  - --forcecompute option to force kernel for compute mode on Polaris (RX470/570/480/580) GPUs. In the Radeon Settings GPU Workload has to be switched to 'Compute'. This option is available in Crimson 17.10.2 (or later) driver and reaches nearly the same performance on Polaris based GPUs as with the Blockchain driver.

  - openCL platform is auto detected if --opencl is not specified

  - --nonicehash option to disable nicehash support

  - nicehash support will automatically disabled if more then 8 GPUs are used. Otherwise search space could be exhausted to early and the GPUs search in overlapping nonce ranges.


Download Cast XMR 0.8 for Windows (64bit)

Happy mining!

[dagarair]

Thanks amigo!

[Morgon]

Hi,

a new version is available:

Cast XMR Version 0.8 (2017/12/14)

  - kernel optimizations result in subtle performance improvements

  - --fastjobswitch option (experimental) to force fast switching to new jobs. When enabled the GPUs will switch to the new job within less then 100ms. This improves the effective hash rate by 1 to 5% as nearly no GPU performance will be wasted on calculating outdated shares anymore. The drawback is a slightly lower displayed hashrate as while switching no hashes are calculated.

Thanks for continuing to work on this. I'm having some weird trouble here; the GPU reports are out of order, and I'm not sure if it's a display issue or a workload issue.

On my 3-GPU system, it will display 2-0-1 (and just switched to 0-2-1 while typing this). My 5-GPU system reports in 4-0-3-1-2 order.  (All are Vega, if that matters)

With --fastjobswitch configured, one GPU will display a report up to two seconds before the others, or sometimes one second after. So far it seems to be one specific GPU each, from both systems I'm running this on.

Is this just a display quirk, or is something else going on?

[glph3k]

Hi,

that the GPUs hashrate output is not ordered anymore is a known behaviour as they report their current hashrate independent. This was a fix when used with GPUs of different type were used sometimes 0.0 Hash/s was reported as one of the GPU was not ready with its task yet.

Will see if it gets sorted again in the next update 

Thanks for continuing to work on this. I'm having some weird trouble here; the GPU reports are out of order, and I'm not sure if it's a display issue or a workload issue.

On my 3-GPU system, it will display 2-0-1 (and just switched to 0-2-1 while typing this). My 5-GPU system reports in 4-0-3-1-2 order.

With --fastjobswitch configured, one GPU will display a report up to two seconds before the others, or sometimes one second after. So far it seems to be one specific GPU each, from both systems I'm running this on.

Is this just a display quirk, or is something else going on?

[deadsix]

Hi,

a new version is available:

Cast XMR Version 0.8 (2017/12/14)

  - kernel optimizations result in subtle performance improvements

  - --fastjobswitch option (experimental) to force fast switching to new jobs. When enabled the GPUs will switch to the new job within less then 100ms. This improves the effective hash rate by 1 to 5% as nearly no GPU performance will be wasted on calculating outdated shares anymore. The drawback is a slightly lower displayed hashrate as while switching no hashes are calculated.

  - improved support for more then 8 GPUs

  - support for Radeon RX 470/RX 570 (Polaris) added

  - --forcecompute option to force kernel for compute mode on Polaris (RX470/570/480/580) GPUs. In the Radeon Settings GPU Workload has to be switched to 'Compute'. This option is available in Crimson 17.10.2 (or later) driver and reaches nearly the same performance on Polaris based GPUs as with the Blockchain driver.

  - openCL platform is auto detected if --opencl is not specified

  - --nonicehash option to disable nicehash support

  - nicehash support will automatically disabled if more then 8 GPUs are used. Otherwise search space could be exhausted to early and the GPUs search in overlapping nonce ranges.


Download Cast XMR 0.8 for Windows (64bit)

Happy mining!

Does not work with AMD Adrenalin drivers. Cast miner is unable to identify OpenCL platform, and specifying 1 does not help either.

[Morgon]

Does not work with AMD Adrenalin drivers. Cast miner is unable to identify OpenCL platform, and specifying 1 does not help either.

Pretty sure this is an issue with the drivers, as evidenced by the fact that no XMR miner benefits from drivers later than the August Blockchain release.

[deadsix]

Does not work with AMD Adrenalin drivers. Cast miner is unable to identify OpenCL platform, and specifying 1 does not help either.

Pretty sure this is an issue with the drivers, as evidenced by the fact that no XMR miner benefits from drivers later than the August Blockchain release.

Yea but should I ask AMD to add support for Cast miner, or should I ask gandalf to add support for the latest drivers, which of the two scenarios seem more likely to happen 

[glph3k]

Does not work with AMD Adrenalin drivers. Cast miner is unable to identify OpenCL platform, and specifying 1 does not help either.

Please try with --opencl=0

[dragonmike]

Thanks for the updated miner, glph3k, testing it out now!

When do you reckon you'll be able to add support for failover pools? That's a feature that's worth a ton of gol... I mean Bitcoin.

Hate not checking the miner for a while and then realising that the damn ETN pool has been down for 3 hours...

[uDwcHYO]

such a good rate of release new versions with the addition of functionality and improvements, the previous release came out not so long ago

[Morgon]

Yea but should I ask AMD to add support for Cast miner, or should I ask gandalf to add support for the latest drivers, which of the two scenarios seem more likely to happen  

The AMD one.  Cast only works on the drivers that are available. If the drivers don't provide the performance, there's nothing glph3k can do.

AMD wouldn't be "adding support for Cast" specifically, they need to fix their autodetection to switch to the integrated Blockchain driver under a Cryptonight workload, as it currently does for Ethash. That's why it's on AMD and not Cast.

[tf2addict]

Hi,

a new version is available:

Cast XMR Version 0.8 (2017/12/14)

  - kernel optimizations result in subtle performance improvements

  - --fastjobswitch option (experimental) to force fast switching to new jobs. When enabled the GPUs will switch to the new job within less then 100ms. This improves the effective hash rate by 1 to 5% as nearly no GPU performance will be wasted on calculating outdated shares anymore. The drawback is a slightly lower displayed hashrate as while switching no hashes are calculated.

  - improved support for more then 8 GPUs

  - support for Radeon RX 470/RX 570 (Polaris) added

  - --forcecompute option to force kernel for compute mode on Polaris (RX470/570/480/580) GPUs. In the Radeon Settings GPU Workload has to be switched to 'Compute'. This option is available in Crimson 17.10.2 (or later) driver and reaches nearly the same performance on Polaris based GPUs as with the Blockchain driver.

  - openCL platform is auto detected if --opencl is not specified

  - --nonicehash option to disable nicehash support

  - nicehash support will automatically disabled if more then 8 GPUs are used. Otherwise search space could be exhausted to early and the GPUs search in overlapping nonce ranges.


Download Cast XMR 0.8 for Windows (64bit)

Happy mining!

I like the openCL auto-detect, that was a hassle.  Any chance we could get the same for GPUs?  It's a hassle to keep having to set the -G parameters for each mining rig.  Most (all) all of the time I just want Cast to use every GPU in the rig.  If you do implement auto detect of GPUs I would recommend adding a switch to disable specific ones, just in case.

[dragonmike]

Could it be that the GPUs are running hotter on this version?... 

Displayed hashrate is a tad lower indeed with the new flag. As long as it's a fairer representation of the true hasrate and submitted shares are actually higher, I'm not bothered!