Cast XMR Version 1.6.6 (2018/11/30)- support for RX 590 GPUs added- fixes for detecting Compute Mode on Polaris based GPUs- support for CryptoNight-SuperFast (--algo=11) for mining Free Haven Protocol (XFH)- updated switch-radeon-gpu to version 1.2.0, which includes bugfixes for newer versions of the AMD Radeon drivers

Cast XMR Version 1.5.0 (2018/9/27)- Support for the Monero V8 Network Upgrade which introduces a new CryptoNight variant CryptoNightV8 aka CNv2. The Monero V8 update is scheduled for 18th October. In case you are mining Monero make sure to update Cast XMR before that date. Also make sure that the algo for Monero is not explicitly set to CryptoNightV7 but set to auto detect with --algo=-1 to automatically switch from CryptoNightV7 to CryptoNightV8 when the upgrade is happening. Please also note that the CryptoNight V8 algo has added complexity which decreases the hashrate up to 7% for Vega GPUs.

Cast XMR Version 1.3.0 (2018/6/29)- Performance improvement for job switches with multiple GPUs- Support for BitTube (TUBE) V4 Pow Update which introduces the new algo CryptoNightTUBE-Heavy aka CN Saber. Stay on --algo=5 to switch automatically from CryptoNightIPBC-Lite to CryptoNightTUBE-Heavy when the update is happening (approx. 2nd July). Please note that the hash rate will drop as it is a switch from a Lite to a Heavy variant.

Cast XMR Version 1.2.0 (2018/6/12)- Fix for "unauthenticated shares" pool error- Support for the upcoming Haven (XHV) V3 update. In case you are mining Haven set --algo=7 now. Cast will then automatically switch to CryptoNightXHV-Heavy when the network update is happening.

Cast XMR Version 1.1.5 (2018/6/7)- Fix for mixed up device order- Support for Stellite (XTL) V4 Update. Add --algo=6 in case you are mining Stellite. It will automatically switch to CryptoNightXTL when the network update is happening.- Stability fixes

Cast XMR Version 1.1.0 (2018/6/1)- All new --intensity option to specify the memory allocation in the range of 0 to 10, upto 12 for Vega Frontier Edition. The default setting will correspond with the settings of version 1.0 and are displayed at startup.- Vega Frontier 'Large Pages' support added, up to 30% higher hash rates for CryptoNight-Heavy, 5% increase for CryptoNight- Includes the switch-radeon-gpu command line tool to restart GPUs, switch on/off HBCC, Compute Mode and Large Pages- Nicehash supports now up to 24 GPUs- --maxmem option is deprecated, will now be mapped to an corresponding intensity setting- --forcecompute is deprecated, 'Compute Mode' of Polaris GPUs will be automatically detected. To overwrite use the --intensity option - Default mining algo changed to CryptoNightV7, to still mine CryptoNight Classic add --algo=0- Tested with Radeon Adrenalin Driver 18.4.1

Cast XMR Version 1.0.0 (2018/4/24)- Support for Aeon (AEON) CryptoNight Lite variant set --algo=3 to mine- Support for Turtlecoin (TRTL) CryptoNightV7 Lite variant set --algo=4 to mine- Support for Interplanetary Broadcast Coin (IPBC) CryptoNight Lite IPBC variation set --algo=5 to mine- Up to 3% performance improvement with new option --maxmem to allocate the maximum memory of the card. For Vega cards the "HBCC Memory Segment" has to be disabled in the Radeon Settings to use the option. Disadvantage is a higher risk of hash rate drops when the --maxmem option is used.

Cast XMR Version 0.9.1 (2018/03/22) - 0.5% overall performance improvement for Vega based GPUs - --ratewatchdog experimental option to monitor the hash rate, in case an occasional happening drop of the hash rate is detected the kernel will be resetted to restore the optimal hash rate - fully tested CryptoNight variant (CryptoNightV7) for the Monero V7 Network Upgrade PoW Change which is now scheduled for the 6th April. - In case you want to mine the Graft coin use the --algo=0 option, an automatic detection of the used CryptoNight variant is not possible for this coin. For all other known CryptoNight coins the hash variant seems to be detected correct - In case you are mining with nicehash.com or any other automatic coin switching pool that has the Graft coin in the mix the --algo=0 option is advised to prevent invalid shares on the Graft coin. Be aware to remove the option when the Monero V7 network upgrade is happpening otherwise it then will clash with mining Monero!

Cast XMR Version 0.9.0 (2018/03/08) - support for the Monero V7 network upgrade. Read more about it here - the Monero PoW switch will be automatically detected, no restart of cast XMR is required. Only make sure to update cast XMR before the network upgrade is happening and that the used Monero pool supports the network upgrade - no decrase in hash rate for other currencies was introduced by the change - CryptoNightV7 will run at the same hash rate as CryptoNight - for any case there is the new --algo option to force which CryptoNight variant to use: - -1 = autodetect (default) - 0 = CryptoNight - 1 = CryptoNightV7 (Monero V7 network upgrade)

Afraid, yes. It is bug in the AMD drivers. It does not matter if HBCC is turned on or off, just a change seems to be needed so that the driver gets correctly initialized. HBCC is a feature to stream data from disk to GPU memory it is a feature for games with huge textures not needed for mining.

Finally. Something interesting. You have qutie the interesting way of structuring your kernels for CryptoNight. And I must say - the number of waves in flight you've managed by doing so is hot.

Thanks, Sir.

Yes, the scheduling is very unorthodox, it uses 2 command queues which are started with an defined time offset. Still searching for an explanation why this faster than one larger queue. The scheduler does get the same work, but for some reason it likes it better that way. Probably very Vega specific but did not yet try it on different cards.

How much power for one of these cards? And where are miners buying them? Is there anywhere reputable that accepts crypto for payment internationally?

Vega 56 uses around 200w of power and most people in the US find the GPUs by price hunting, Newegg is a good spot to try to snipe these and they do accept Bitcoin for payment. In the US reddit’s /r/buildapcsales regularly posts nice deals for these cards.

Finally. Something interesting. You have qutie the interesting way of structuring your kernels for CryptoNight. And I must say - the number of waves in flight you've managed by doing so is hot.

Thanks, Sir.

Yes, the scheduling is very unorthodox, it uses 2 command queues which are started with an defined time offset. Still searching for an explanation why this faster than one larger queue. The scheduler does get the same work, but for some reason it likes it better that way. Probably very Vega specific but did not yet try it on different cards.

Don't you want to try with Dagger-Hashimoto?Cryptonight already has good multithreaded miner - xmr-stak-amd and your miner doesn't outperform it ...

Finally. Something interesting. You have qutie the interesting way of structuring your kernels for CryptoNight. And I must say - the number of waves in flight you've managed by doing so is hot.

Thanks, Sir.

Yes, the scheduling is very unorthodox, it uses 2 command queues which are started with an defined time offset. Still searching for an explanation why this faster than one larger queue. The scheduler does get the same work, but for some reason it likes it better that way. Probably very Vega specific but did not yet try it on different cards.

Don't you want to try with Dagger-Hashimoto?Cryptonight already has good multithreaded miner - xmr-stak-amd and your miner doesn't outperform it ...

Yeah, xmr-stak-amd - the miner which stole my code, violating its MIT license, and then had the balls to put a fee in it for himself.

Sorry, I'm not strong in licenses. xmr-stak-amd code is open sourced, contains reference to you and you can set fee to 0 and compile.Moreover it has nice additional features and runs on Vega. Public sgminer with your kernel doesn't.

Finally. Something interesting. You have qutie the interesting way of structuring your kernels for CryptoNight. And I must say - the number of waves in flight you've managed by doing so is hot.

Thanks, Sir.

Yes, the scheduling is very unorthodox, it uses 2 command queues which are started with an defined time offset. Still searching for an explanation why this faster than one larger queue. The scheduler does get the same work, but for some reason it likes it better that way. Probably very Vega specific but did not yet try it on different cards.

Don't you want to try with Dagger-Hashimoto?Cryptonight already has good multithreaded miner - xmr-stak-amd and your miner doesn't outperform it ...

Yeah, xmr-stak-amd - the miner which stole my code, violating its MIT license, and then had the balls to put a fee in it for himself.

and its still slower than sgminer why dont you pay him back and release his miner without fee?

Nice job, is this limited to only 4 Vega per motherboard like xmr-stak is, as well? Does it play nice with mixed gpu rigs with nvidia and amd?

Thanks! The app should have no limit how many GPU used in parallel, probably more a driver issue.

Currently it is only one GPU per instance. One can select with "--opencl n" the OpenCL plattform to use (Nvidia, AMD, Intel) which number is the correct one is probably experimenting. And with "-G x" which device to use. There is no programmed limit how many instances one can start, One process needs only 100 MB memory when running.

After testing it says [Suspicious link removed]pute driver not installed. The blockchain driver is all I have installed, is this still miner only working for one gpu?

Oh, which version of the blockchain driver do you have? (I only know of the 17..30.1029 Beta from Aug 23).

Yes, only one GPU per instance (maybe gone change that) and only Vega GPUs, because of the simple fact I only have those and my goal is to get the most out of it. There are no plans to support any other cards, beside maybe the RX 480/580 but it never will be a generic miner replacement...