Topic: CCminer(SP-MOD) Modded NVIDIA Maxwell / Pascal kernels. - page 775. (Read 2347664 times)

Is suprnova pool  pps  or  per block? plz    thx

My .bat is ccminer.exe -a vanilla -o stratum+tcp://vnl.suprnova.cc:1118 -u x -p x -q -i 25 -s 30 -d x
I am not getting 2.7 Ghash in my MSI GTX 970 4G

My room temp is 20C. GPU temp 80C. Should I OC a bit ?

CRYPTOMINING-BLOG.COM--

There are 2 posts in the last 2 days regarding VanillaCoin.  There is one post from the 27th of January with a link to several mining packages, including tpruvot's 1.7.2:

http://cryptomining-blog.com/wp-content/download/vanillacoin-blake256-miners-windows.zip

and one post, also from the 27th of January, with sp_' s release dot 78:

http://cryptomining-blog.com/wp-content/download/ccminer-1.5.78-git-spmod-vanillacoin.zip

I am probably going to try sp_ 's version later today.       --scryptr

can you tell me the download link of v1.7.2 please

VANILLACOIN--

After reading the buzz posts on VanillaCoin (VNL), I downloaded and set up tpruvot's CCminer v1.7.2.  With my EVGA GTX 960 SC, I get the standard 1.7GH/s on SuprNova's VNL pool.  In the last hour I've earned over 1 VNL, mining with just the single card.  I am at a 99.42% acceptance rate with more than 600 accepts.

I hope that release #6 of sp_s Private Miner is optimized, I may set some of my larger rigs on the coin.  It is trending up on the markets.       --scryptr

how profitablel the new vanillacoin algo on maxwells?And Sp do you have any optimisaztion about this algo?  

I'm using that currently, it's about 10% slower then your version (unless it's faster because of duplicate shares).

Use the official version. They are using my optimized kernal as well..

X11 and quark only read memory linary. In my mod I use vector instructions in the gpu to load many 32bit words in one instruction.

if you compile this to ptx you will see what I meen.

#include "cuda_vector.h"
...
   uint32_t h[16];
   uint28 *phash = (uint28*)hash;
   uint28 *outpt = (uint28*)h;
   outpt[0] = phash[0];
   outpt[1] = phash[1];

I'm not getting what your saying. It's not about repeated accesses to the same data it's about access to
different data in the same cache line only once. Preloading the cache line with the initial load instruction
means the subsequent data wil be available sooner.
Anyway SP doesn't seem interested and it's his thread so I should probably drop it.

You're not getting the real issue here - GDS is read ONCE. ONLY ONCE. In pretty much all X algos. Well, per kernel.

Cryptominingblog rebuilt the latest and either it doesn't work or they compiled it wrong.
http://cryptomining-blog.com/wp-content/download/ccminer-1.5.78-git-spmod-vanillacoin.zip

NO, NO, NO. The swizzle operation, like LDS and GDS loads, take TIME. Clock cycles. If you try and use the result without using s_waitcnt to be sure that the operation has completed, more than likely you'll be reading garbage. The likelihood of this occurring becomes greater and greater the closer your read instruction is to the load instruction that must be waited on. Or, more accurately, how few clock cycles have passed.

The uint4 I named a is already in registers - if you wanna walk it back, it's actually from an AES operation before, which may be done via LDS lookups into a table and XORs, or a bitsliced AES S-box followed by an otherwise mostly classic-style AES implementation.

I think your misunderstanding is that you think v_xor_b32 queues something. It doesn't. ds_* instructions you might be able to say "queue" something, in the sense that they trigger an LDS read/write and immediately allow for the next instruction to be executed. v_xor_b32 is an immediate XOR of two registers. It couldn't give a fuck less what's in them, or what you meant to put in them - it's going to XOR them and put the result into the destination register, and if it's not what you intended it to be, that's your problem.


Keep in mind - there is no swizzle for the uint4 named a - the first row is not shifted. This is why you don't see any swizzle ops for it - it is entirely contained within the single work-item. This is why I swizzle b, then c, and then begin my XORs. Keep in mind, again, that this triggers the start of the swizzle and immediately goes to the next instruction - this means if I do b AND c one after another, and only wait on b in order to XOR it with a, I'm putting more clock cycles between the time I initiated the swizzle for c, and the time I need it to complete. It's entirely possible that by the time I call on s_waitcnt to ensure the c variables are ready, they already are and the instruction takes basically no time at all.

You're also thinking about cache, which doesn't apply here at all - swizzle is a 4-way crossbar that allows transfer of values between work-items on a compute unit. In addition, even if it wasn't, I couldn't give a fuck less if it's in the cache - hell, I'd rather it NOT be. Why? Simply because I just loaded those values into registers, and were they in memory, I would never be reading them from memory again. X11 and friends can be done using ZERO global memory at all (besides getting work, storing the state for the next kernel, and output, of course) - if you work at it, it can even be done without using LDS for storage of shit like AES tables. Now, you *may* want to use LDS for other reasons to create an optimal GPU implementation, but these are related more to parallelizing the hash functions more, by unrolling them across multiple WIs (like this Echo-512 we're discussing), rather than actual storage of data that's honestly needed to compute the hash function. Because of this, cache is really irrelevant, and in an extremely well optimized X11 kernel set, you should be able to downclock memory to hell and have it not matter one iota.

Fun fact: This is why the claim of X11 being "ASIC-resistant" is more or less a flat out lie. What most people call "ASIC-resistant" is actually "ASIC-unprofitable" - meaning that the ASIC would cost so much that its advantage over the currently used mining hardware doesn't justify making it. Usually, this is done via memory usage, at least for now. But X11 isn't memory-hard - shit, it doesn't really need memory at all, especially if implemented in hardware.