CCminer(SP-MOD) Modded GPU kernels.

[sp_]

X16rv2 is FPGA shit algo, you better start optimizing the FPGA bitsream to 5Ghz or so for a fee  

I'm just testing the new cards and algo. I've got a rtx 2070 and a rtx 2060 SUPER.
In x16rv2 I managed to remove the new tiger192 completely from the SHA512, and partly on luffa and keccak. By merging the tiger into the other kernels the gpu can do the new multiplications and AES in the tiger192 in parallell.

So the new X16v2 will perform close to  the speed of the old x16r on the gpu, and fpga's will slow down mostly because of the multiplications.
A bether FGGA killer would be to generate PTX kernels runtime for each block by permuting the assembly instructions. The instuctions should include multiplications, logic, scrambling. The gpu miner will need to compile the ptx on the fly for every block before warping. Then the FPGA implementation would need to have an ALU (cpu emulation) and this will slow down alot.

[sp_]

What about older cards?

Some RTX optimalizations doesn't work on gtx cards. In the code I have split execution on some of them rtx optimized kernel/gtx optimized, but not all of them.  If I do the splitting x17 will do around 24MHASH on the gtx 1080ti. ccminer 1.0 alexis is around 20MHASH.

F.ex reverting cubehash-shavite to the old version you gain a megahash on 1080ti.

To get the opensource up to date with the latest fee miners is more work. The opensource SIMD is slow and need to be rewritten. I have extracted the latest t-rex ptx code. PM me if you want to help reverse engineer to cuda and opensource.

[pallas]

sorry to say but FPGA hashrate of x16rv2 will be the same as the old x16r

[sp_]

Let's see what the result will be after the fork. X16v2 will remove the ASIC'S and x16v3 can remove the fpga'a
Ravencoin could hardfork again in 2 months to a randomhash variant with permuted instructions in the hash x16v3, and then the FPGA's will have to mine something else. An optmized x16rv2 could do around 35MHASH on 65 watt's on the RTX 2060 SUPER.

[joblo]

The problem is x16rv2 isn't any more ASIC resistant than v1. All it really needs is development
of a Tiger kernel which shouldn't be too difficult. The only thing that would prevent it is lack
of market demand. Lyra2v3 has a similar problem.

It's not easy to make an algo GPU friendly and ASIC resistant. It would have to target a resource
that GPUs have in abundance that would be too expensive to implement on an ASIC. I'm not aware of any.

Permuted instructions can be worked around with a RAM code segment so it just increases RAM requirements.
A bigger dataset has the same effect. Ironically Lyra2REv2 used a smaller dataset than Lyra2RE to give GPUs
an advantage over CPUs. Lyra2REv3 did not change the size of the dataset.

In the end coins that fork to new algos periodically as an anti-ASIC strategy do little more than create
a planned obsolenscence environment driving demand for new ASICs.

[sp_]

The problem is x16rv2 isn't any more ASIC resistant than v1. All it really needs is development
of a Tiger kernel which shouldn't be too difficult. The only thing that would prevent it is lack
of market demand. Lyra2v3 has a similar problem.

I expect a decline in the difficulty after the fork. Look what happened in the Beam II fork.

Permuted instructions can be worked around with a RAM code segment so it just increases RAM requirements.

You need to read the instruction from ram decode and execute. Difficult to make the fpga run at full speed.  You can create a superscalar version that execute more than one instruction per cycle, but still much slower than a static hash function. Or is it a faster way?

[bensam1231]

Depending on the market there isn't demand for new ASICs (due to price of development and emission), FPGAs are the new ASICs and much more difficult to deal with. What further exasperates the issue is that the bitstreams for them are generally relegated to smokey back rooms where most people don't have access. So even if you find and buy the really expensive hardware, you don't have access to the software to run on them.

This is an awful lot like the scrypt days where people were making miners for algos and trading them in back rooms while ASICs were just starting to emerge. This entire last year or so has been dominated by this behavior, matched with market decline and over bloat of hash (along with dark hash) has lead to a relatively stark outlook.

GPUs DO have things that FPGAs don't have, which is a much lower price tag and memory. So then it comes down to hash per/$. If FPGAs give little to no advantage for the price you're paying for them, there is no reason to use them. Memory is only on a couple FPGAs and depending on which one you're talking about, it's not the best in the world, which further limits performance.

A lot of the current predicament, putting aside the market decline and bloating of hashrate caused by the boom in '18, has to do with coin devs being lazy. There are a lot of algos that are much more asic resistant then others, instead they do stupid shit like what RVN is doing by slightly altering their algo to maintain a brandname and appearing progressive, without actually tackling the problem. It's not even about having a silver bullet either, they can just swap for already available algos. MTP and Progpow for instance are very asic/fpga resistant (for now).

[pallas]

There are HBM equipped FPGAs already.
Problem is, even with restricted bitstreams, their ROI is close to infinity. Just like with ASICs.

[sp_]

There are HBM equipped FPGAs already.
Problem is, even with restricted bitstreams, their ROI is close to infinity. Just like with ASICs.

So the next question is how many times can you access the HBM per cycle.
In my algo proposal you will have a random stream of instructions for every new block. (15000 PTX instructions / 15 sec blocktime).
On the GPU you will just run the ptx. (cuda will compile and cache the code before execution and it will take a few milliseconds). After the compilation has been done, you get 14.xx seconds left to run the compiled kernel in full speed. On the FPGA you cannot generate the VHDL code compile and flash in 15 seconds, so you need to make a CPU emulator. This is because it would probably difficult,slow or impossible to generate VHDL out of random instructions and run it without timing bugs.

[joblo]

So the next question is how many times can you access the HBM per cycle.
In my algo proposal you will have a random stream of instructions for every new block. (15000 PTX instructions / 15 sec blocktime).
On the GPU you will just run the ptx. (cuda will compile and cache the code before execution and it will take a few milliseconds). After the compilation has been done, you get 14.xx seconds left to run the compiled kernel in full speed. On the FPGA you cannot generate the VHDL code compile and flash in 15 seconds, so you need to make a CPU emulator. This is because it would probably difficult,slow or impossible to generate VHDL out of random instructions and run it without timing bugs.

By using PTX you're esentially using a proprietary language to prevent anything but a Nvidia product
or a Nvidia licensed product from mining your algo. That's one way to make an algo ASIC/FPGA resistant.

[bensam1231]

There are HBM equipped FPGAs already.
Problem is, even with restricted bitstreams, their ROI is close to infinity. Just like with ASICs.

If you're talking about FKs they aren't even being shipped and they don't even talk about what algos they'll support. Either way, as I mentioned FPGAs with memory (specifically fast memory) are in the extreme minority. They aren't everywhere.

Anti-FPGA effort is not a silver bullet. They're a lot more expensive to produce so you make something that makes it extremely expensive to produce then there has to be a huge reward on the other side or it's not worth it. Looking at 2-3 year ROI on a lot of FPGAs, even if they produce a lot of hashrate makes them very unpalatable. There is opportunity cost associated with everything a lot of people don't consider that. FPGAs also become obsolete and obsolescence is something that has to be considered. So even if you have a FPGA that will ROI in 3 years, there can and more then likely will be newer ones out that will obsolete those.

Chinese don't respect licenses or IP rights unless it's some megacorp and you have millions to throw at it with lawyers.

[pallas]

There are HBM equipped FPGAs already.
Problem is, even with restricted bitstreams, their ROI is close to infinity. Just like with ASICs.

So the next question is how many times can you access the HBM per cycle.
In my algo proposal you will have a random stream of instructions for every new block. (15000 PTX instructions / 15 sec blocktime).
On the GPU you will just run the ptx. (cuda will compile and cache the code before execution and it will take a few milliseconds). After the compilation has been done, you get 14.xx seconds left to run the compiled kernel in full speed. On the FPGA you cannot generate the VHDL code compile and flash in 15 seconds, so you need to make a CPU emulator. This is because it would probably difficult,slow or impossible to generate VHDL out of random instructions and run it without timing bugs.

what will happen when cards compatible with the language are no longer produced?
maybe you are planning a pump and dump coin so you don't care :-D

[sp_]

By using PTX you're esentially using a proprietary language to prevent anything but a Nvidia product
or a Nvidia licensed product from mining your algo. That's one way to make an algo ASIC/FPGA resistant.

Doesn't need to be PTX. You need a pseudo Assembly language that can easily be translated to ptx before execution.
The CPU miner would have to parse this language and create proper native binary before execution. (Create instructions in memory, flush the caches, then execute ) CPU verification is important for the pool/wallet/exchanges.

[sp_]

what will happen when cards compatible with the language are no longer produced?

The point with ptx is that it's a unified language for all NVIDIA gpu architechtures. The ptx is compiled to the native gpu language by the NVIDIA driver before execution. If NVIDIA decide to replace PTX with SPTX, you simply need your miner software to convert the random hashing function into SPTX.

[pallas]

By using PTX you're esentially using a proprietary language to prevent anything but a Nvidia product
or a Nvidia licensed product from mining your algo. That's one way to make an algo ASIC/FPGA resistant.

Doesn't need to be PTX. You need a pseudo Assembly language that can easily be translated to ptx before execution.
The CPU miner would have to parse this language and create proper native binary before execution. (Create instructions in memory, flush the caches, then execute ) CPU verification is important for the pool/wallet/exchanges.

Yeah, no PTX, that's what I was saying.
==> RandomX

[sp_]

Yeah, no PTX, that's what I was saying.
==> RandomX

So to make a fast randomx miner on NVIDIA you can convert the randomx code to ptx before execution. (Create a new ptx kernel for each block)

Without optimalizations the NVIDIA cards are loosing to the CPU.

randomx benchmarks:

https://bitcointalk.org/index.php?topic=5176747.0

GPU	Cryptonight-R	RandomX
AMD
Vega 64	2200 H/s	1225 H/s
RX 480/580	960-1000 H/s	400-410 H/s
RX 560 4GB (1400/2200 MHz)	495 H/s	260 H/s
NVIDIA/EVGA
RTX 2080 Ti (1915/13600 MHz)	960-1000 H/s	400-410 H/s
GTX 1080 Ti (2037/11800 MHz)	927 H/s	1122 H/s
GTX 1070 Ti (1900/7600 MHz)	625 H/s	769 H/s

For CPUs:

CPU	Cryptonight-R	RandomX
AMD 3900X (4.25GHZ ALL CORE, 3600MHZ RAM)	1335 H/s	13330 H/s
RYZEN 3700X	1018 H/s	6853 H/s
RYZEN 5 3600	803 H/s	6580 H/s
INTEL I9 9900K	630 H/s	2102 H/s
2X XEON E5 2670 V2	930 H/s	5815 H/s
INTEL I7 7700K	350 H/s	2100 H/s

[joblo]

The point with ptx is that it's a unified language for all NVIDIA gpu architechtures.

The point s that it's only Nvidia GPU architectures. No ASIC, no FPGA, no Radeon, no CPU.

[sp_]

The point with ptx is that it's a unified language for all NVIDIA gpu architechtures.

The point s that it's only Nvidia GPU architectures. No ASIC, no FPGA, no Radeon, no CPU.

Doesn't need to be PTX. If you run on NVIDIA hardware you convert the random stream of instructions to PTX. RandomX could be very profitable on NVIDIA hardware with a proper implementation...

[joblo]

Doesn't need to be PTX. If you run on NVIDIA hardware you convert the random stream of instructions to PTX. RandomX could be very profitable on NVIDIA hardware with a proper implementation...

Precisely. You can build a Nvidia-only proof of concept, but a real product will need
it's own pseudo language that can be compiled to ptx/cuda, ocl, and x86 native instructions
producing identical functionality. The language would have to complex enough (in the CISC sense)
that the FPGA can't decode with a simple table lookup. That's a hell of a lot of work.

[sp_]

The language would have to complex enough (in the CISC sense) that the FPGA can't decode with a simple table lookup. That's a hell of a lot of work.

The FPGA have limits to memory access and multipliers. Let's say the FPGA can do 32 multiplications and 32 mem access per cycle, then you might be able to run 32 instruction per cycle. @500mhz


RandomX on the gpu doesn't need any memory access because the code is compiled, and you can run with 1024 threads at 2000Mz.

So the gpu can do 1024 instructions per cycle@2000mz