Hash on gpu?

Started by
6 comments, last by Ravyne 8 years, 6 months ago

Hi, i just wanted to know if it's possible to compute a hash on the gpu, like crc32 or something stronger(sha-1?)

, in an efficient manner? If so, how, how would i retreive the result?

Advertisement

Take a look at some of the bitcoin mining software out there, you might find some that can still hash on GPU. There should be some on github and the like

This looks promising http://shader.kaist.edu/sslshader/

Unfortunately appears to be closed-source

Eric Richards

SlimDX tutorials - http://www.richardssoftware.net/

Twitter - @EricRichards22

The question I am asking myself is why do you want to do this on the GPU. If its just to have a resource name changed in a hash the CPU will do fine for that.

Worked on titles: CMR:DiRT2, DiRT 3, DiRT: Showdown, GRID 2, theHunter, theHunter: Primal, Mad Max, Watch Dogs: Legion


Hi, i just wanted to know if it's possible to compute a hash on the gpu ... in an efficient manner?
Nope. Hashes are mostly sequential in nature. Fetching the result of stage N as input to stage N+1 is common. In some cases, steps might have side-effects which might force you to run them fully sequentially.

This implies hashing generic data blobs cannot saturate the GPU ALUs.

What you can do however is to use a merkle tree - an array of hashes of partitions - and them somehow combine them. Here are some pictures.


If so, how, how would i retreive the result?
You just read a buffer as usual.

Note however for game related purposes (of identifying resources or similar) there's likely not much of a point in transferring the data over PCIex. For some small data the latency involved can probably negate the benefits. On iGPU we might talk but in general I would second NightCreature' suggestion.


Take a look at some of the bitcoin mining software out there, you might find some that can still hash on GPU. There should be some on github and the like

FYI, GPU mining is still very much around albeit not in BTC specifically. They're not generic hashers anyway as they hash 80-byte blocks which change value according to a set of rules. Furthermore, it is very common to confuse the property of the hash itself with the properties of the (parallel) scanHash operation. In short, I wouldn't suggest to take a look at them, the host code is particularly ugly.

Note: I am the author and maintainer of one of such apps. Of course mine is... fairly different.

Previously "Krohm"

The question I am asking myself is why do you want to do this on the GPU. If its just to have a resource name changed in a hash the CPU will do fine for that.

Hashes aren't used exclusively for mapping resource names to numeric identifiers...

“If I understand the standard right it is legal and safe to do this but the resulting value could be anything.”

It is of course possible to do this on the GPU (there was a chapter in one of the earlier GPU Gems books about it if I recall correctly, also GPU-side calculation of hashes is what cyber criminals commonly use to retrieve hashed passwords), and in an efficient manner. However, there are a couple of important "if"s attached.

The question is what exactly you want, and knowing the difference between the methods. Then you can tell whether it's a good design for what you want to do.

Calculating one hash on the CPU means running some 10-20 cycles worth of simple instructions per byte over your data, and after that you have the result in a register. Calculating one million hashes means it takes a million times as long (possibly a little less, you can still multithread, too).

Calculating one hash on the GPU means calling a more or less elaborate API to get access to a driver-owned buffer (taking a few dozen to a few hundred cycles), copying your data into the buffer (taking almost as long as calculating the hash on the CPU for simple hashes!), initiating a PCIe transfer (taking tens of thousands cycles), then almost instantly generating the result, and waiting another ten thousand or so cycles for the driver to do the PCIe transfer back. Then you call another API function to retrieve the result.

On the other hand, for one million hashes or for ten million variations of a certain small bit of data (say, a password), you still have the same fixed, identical overhead for bus transfers and API calls, but you still get the actual result done "almost instantly" (because GPUs are very fast, and massively parallel).

So whether it makes sense to calculate a hash or not mostly depends on the question "Do you need one or do you need millions?".

For most applications and most people (antivirus companies and cyber criminals exempted) the answer is therefore "no".

The question I am asking myself is why do you want to do this on the GPU. If its just to have a resource name changed in a hash the CPU will do fine for that.

Hashes aren't used exclusively for mapping resource names to numeric identifiers...

In the context of gaming however that is the most common use, I know that hashes are used for other things too.

Worked on titles: CMR:DiRT2, DiRT 3, DiRT: Showdown, GRID 2, theHunter, theHunter: Primal, Mad Max, Watch Dogs: Legion

Maybe I'm mistaken, but isn't it actually the case that GPUs aren't particularly good for calculating the hash, they are serial after all? GPUs are great for crypto-currency mining and password cracking because those things involve computing (possibly) the entire set of all hashes and looking for one among them that satisfies given properties (e.g. in bitcoin, a hash which has the correct number of leading zero bits for the current difficulty). You might want to calculate a hash of data already on the GPU, in which case its probably faster to do it there, but its probably not a win to shuffle data to the GPU just to take any old hash (but probably if you want to generate one with special properties).

throw table_exception("(? ???)? ? ???");

This topic is closed to new replies.

Advertisement