Quote from: Claymore on September 22, 2017, 08:46:50 AM

Quote from: Wolf0 on September 21, 2017, 09:24:37 PM

Quote from: bitnoob1234 on September 21, 2017, 07:47:29 PM

Quote from: Claymore on September 21, 2017, 03:03:39 PM

I decided to upgrade this miner to common codebase that I use for dual and zcash miners, it will take additional 2-3 days. I'll try to release new version this weekend, but no guaranties.

Vega support?

I kind of doubt it based on his tenative ETA, but maybe. Reason being, he says he's already gotta update the framework to the same one he uses for his other miners, which I'm guessing isn't a super simple task given how long this miner has been unchanged (during which time he's released quite a few updated to his other miners.) Adding support for Vega that is presentable isn't super simple, either, as optimizations for new ISA extensions do take a bit. This might be made simpler if he leverages some of the more advanced features of the new LLVM/Clang toolchain used for ROCm, though.

Additionally, even if he wanted to rush out a basic implementation of Vega support, he also is at least somewhat mindful of protecting his intellectual property: he won't be able to embed his kernels for Vega like he has done for some of the others (as AMD IL), simply because Vega only works with the new ROCm stack, and there IS no AMD IL used anymore. Since there's really only one GCN version which MUST be used with ROCm, though, I suppose he could simply embed it as ISA like he's done with some others. Plus, then, he has to thwart the common debugging/analysis angles that he's already covered for the old, Catalyst based shit (such as GPU_DUMP_DEVICE_KERNEL, or AMD_OCL_BUILD_OPTIONS_APPEND environment variables.)

So, for him, it's not likely to be a simple and straightforward implement and then run the executable through his packer of choice (I believe this is VMProtect for his Windows based ones, his Linux based ones he uses a stub which loads one of the bin files in the current directory, transforms it using appears to be a custom permutation, and then executes it - this new binary is packed with UPX (I forget which version it is now; also, see footnote.))

Footnote: Claymore, you don't have to respond - in fact, I'm fairly sure you won't - but please, for the Linux miners... at least clobber the UPX signature on the decoded Data3.bin. That really was a glaring inattention to detail, IMO.

1. CN miner is rather old, it was created in 2014, and I rarely updated it. For dual and zcach miners I made hundreds of updates in code, I cannot apply them all to this miner easily. So I have to move stratum/kernels code and related stuff to latest framework. Not a complex task, but to make everything work properly, I will have to spend a couple of days at least.
2. Vega support for Windows - yes. For Linux - not right now, my devtools for asm don't work with ROCm, I will have to spend some time to add it.
3. I'm not going to create any good protection for Linux, it's impossible for opensource OS. So if you have some skills you can crack it and be happy

PS. UPX license does not allow you to change generated binary. Anyway, changing signature is too easy, I could change entire compression method, but I have much more important things in my todo list.

"but I have much more important things in my todo list" - kind of? just curious
If it is not a secret or secrets - it will be great to hear just some of them