Topic: Claymore's CryptoNote AMD GPU Miner v11.3 - page 108. (Read 2145056 times)

Hi claymore,
i sent an message to you.
did u read it ? 
regards

ROCm does not support Windows, so I'm not going to migrate to it. Also I'm not interested in inline asm and don't have to write in asm directly. Instead, I created own opencl compiler and now I don't care about any limitations or issues.

About Vega support on Linux - really, I know you're not a Linux type guy... but you honestly should check that shit out. AMD worked with the LLVM/Clang people to get complete support for pretty much every GCN version up to Vega. Now, you're probably thinking that you more or less have the same shit on Windows... but the killer feature of the new toolchain (for me, at least), was the fact that you no longer should ever have to write your kernel in nothing but ASM starting from the ground up, or as I did sometimes, feed the AMD Catalyst OCL compiler some C that it hopefully doesn't fuck up too badly with, and then disassemble the result for (usually quite substantial) modifications. Instead, you first have complete (more or less) control over the emitted ISA through the use of inline assembly. While it is currently slightly stupid (for example, if told that it is to take three uints as input, one uint as output, and via the constraints you aren't specific enough and instead of specifying the TYPE of GPR (VGPR or SGPR - there's a generic constraint that simply specifies it must be a GPR and the compiler should decide), you tell it to simply use a register... it might choke when building due to the register allocator deciding to emit ISA to the assembler that is impossible to encode. In my case, it was that it attempted to use v_alignbit_b32 with a VGPR as the output, one more VGPRa as a param, and the other two params as SGPRs, which is illegal. Fixing it was simply a matter of being slightly more strict with my constraints. They even have a LARGE set of AMDGPU-specific intrinsic functions that also can be used in your OCL. Many, many kinds of common cases where one would otherwise find inline assembly the best option has been simplified even further through the use of the new builtins. The first ones that spring to mind for me are the ones which expose ds_permute_b32 and ds_bpermute_b32 to the developer in a neat and clean built-in function.  Other than the little issue I found with the register allocator being a bit dumb if I give it too much freedom (which was trivially diagnosed & fixed) - I honestly have hit far less bugs in this than the old Catalyst compiler... which offers a fraction of the functionality!

As for no good *nix protections... awww. I'm not actually interested in circumventing the devfee - it's just somewhat fun; ceases to be so if you don't really try, though! Anyways - I totally get it; I don't agree it's a lost cause (well, not any more so than it being a lost cause on Windows, or any other OS), but God knows it's quite a bit more of a pain in the ass to deter someone when your program is run under *nix instead of Win.

Shit - good one spotting the license on UPX. I didn't know that.

Hi,

Would you recommend buying RX580 rx 580 red devil 8GB?
Also will you power only 8Pin or need 6 Pin+8 Pin need to be connected to PSU?
Thanks

Thank you
i agree with you but can suggest a coin for this
i have another rig consists of 3 RX 580 + 2 RX 570 all minig etherum and i cannot attach R7 265 with them cause it's 2Giga and cannot mine etherum
is it more profitable to attach it with them and mine monero than stay the same and mine etherum as it

Thank you
i agree with you but can suggest a coin for this
i have another rig consists of 3 RX 580 + 2 RX 570 all minig etherum and i cannot attach R7 265 with them cause it's 2Giga and cannot mine etherum
is it more profitable to attach it with them and mine monero than stay the same and mine etherum as it

Thank you
i will buy if i get some money but
until i buy can i profit from this gpu

hi guys
need your help
now i have Sapphire R7 265 and using claymore for mining in https://moneropool.com/ and have 415 H\s
the problem is the profit is weak specialy after hardfork v6 a few days ago i can make about 0.004 XMR after i was get 0.01 XMR before hardfork v6
need your suggestions

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.

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.

I think beside Inverter we still need Solar Panel for that.

Hm.. can you please explain it?