Almost nobody does any free opensource optimizations anymore.

If I release a faster kernel the closed source miners will use a couple of days, steal my hard work and put a 1% fee on top of it.. Bad for business. But on the other hand, if nothing is done about the speed, gpu mining for small gpu miners in many of the well known algos could be history.

This miner is not updated anymore. I did a quick test of the x17 algo on my RTX 2060 SUPER. The latest ccminer 2.3 does around 9MHASH,The popular alexis 1.0.0 fork is doing around 12 MHASH My free opensource suprminer/SPMOD-GIT is doing 19MHASH. The private miner Enemy/T-rex & co is doing around 26MHASH.
But it all doesn't really matter because there is no profit in 26MHASH.

Is X17 FPGA/ASIC minable, or is there a faster Private GPU kernel out there that harvest all of the profit?

t-rex is not optimized to the maximum.

The difficulty went from 320 to 100 after the hardfork. Raven is profitable on the GPU again...
It also made a message to the Asic devs. Ravencoin is ready to hardfork again at a later stage...

Winter is coming. Some ppl use rigs to heat their homes.

Beam can be mined with 3gb cards. gminer.  (windows 7,8.1 or linux)
Grin29 can be mined with 4/6gb cards. gminer (windows 7,8.1 or linux)
for 2gb cards monero  / randomx?

T-Rex is slow and not profitable. Bether to mine Beamv2 or Grin.

With a compiled kernel, the GPU can execute 15000 Randomx Instructions in 15 cycles per hash@2000mhz.

Yes, but in Randomx the FPGA need to do a memory read per cycle to determine the instruction to be executed so the N hash doesn't apply. Then the new limit is N instructions where N is limited by the number of memory accesses the chip can do per cycle. In older FPGA designs it was normal to have ASIC multipliers you could use to speedup multiplications (f.ex Altera Cyclone IV). The multiplication could also be done in code.

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

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...

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

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.

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.

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.

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


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?

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.

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.

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.