Vulkan compute shaders

[mrh]

I've been trying out coding up a few simple things using Vulkan compute shaders, instead of OpenCL. It seems pretty cool so far.
I was thinking of taking a shot at converting mfakt[oc] into a vulkan mfaktv. It would be fun to compare performance. Has anyone already tried something like this? Is it a dumb idea?

[M344587487]

Last time I looked it seemed hard to do generic compute with vulkan because vulkan is so focused on rendering, but that might have changed and I have little experience to be a good judge. It's worth exploring especially if you've had success implementing more trivial but definitely non-render-type compute in vulkan already. It might be much harder than OpenCL to get running performantly on different hardware types, and there might not be much to gain besides compatibility and maybe less overhead, but AFAIK no one has seriously tried and these are just my assumptions.

If you've found good resources on doing generic compute on vulkan please post them here, it's an interesting rabbit hole to learn about.

[mrh]

Originally Posted by M344587487

Last time I looked it seemed hard to do generic compute with vulkan because vulkan is so focused on rendering, but that might have changed and I have little experience to be a good judge. It's worth exploring especially if you've had success implementing more trivial but definitely non-render-type compute in vulkan already. It might be much harder than OpenCL to get running performantly on different hardware types, and there might not be much to gain besides compatibility and maybe less overhead, but AFAIK no one has seriously tried and these are just my assumptions.

If you've found good resources on doing generic compute on vulkan please post them here, it's an interesting rabbit hole to learn about.

I found this example and thought it did a nice job showing how to get stared on the CPU side. I started with that. I think I can figure out the GPU compute side. I have a lot to learn wrt to other things, for example the vulkan memory models.

I was able to build and run just by installing a few packages from the standard ubuntu distro. I'll keep digging into it and see what happens.

thanks!

[mrh]

So I changed by path a bit. I've started converting gpuowl.cl into GLSL that compiles to SPIR-V to be used as a vulkan compute shader. I'm testing little bits as I go. Learning a lot about gpuowl and vulkan as I go. Fun! The bit-wise manipulations of floats/doubles had me stuck for a bit, but I figured out how to make those work well now.

[moebius]

seems to be a lot of work but useful, respect!

[M344587487]

Have you looked into this or something like it? https://github.com/google/clspv

No idea how far along that project is and it probably isn't as simple as press a button to transpile,but with luck it may be able to do some legwork.

[mrh]

Originally Posted by M344587487

Have you looked into this or something like it? https://github.com/google/clspv

No idea how far along that project is and it probably isn't as simple as press a button to transpile,but with luck it may be able to do some legwork.

I did, but I think I should look at it again. Thanks!

[mrh]

I had a little spare time so I wrote a very simple trial factor implementation as a Vulkan shader. It implements simple 96 or 128-bit integer math. It doesn't yet do any fancy montgomery, barrett, etc optimizations. I wanted to make sure I understood enough to make a working TF first.

On a Radeon VII it can test > 100M k-values/sec, so not mfakt[co] speeds, but still interesting.

Shader code is here: https://github.com/mrh42/vtf/blob/main/tf.comp

[kriesel]

Kudos! How did you choose a value for NK? What GPU utilization do you see in GPU-Z or similar, vs cpu utilization of the process in Task Manager (Win) / top (Linux)?

const int ntestprimes = 160;  // tweak as needed

This seems small to me. You may gain more performance by sieving out more candidate factors, with more known small primes.

[mrh]

Originally Posted by kriesel

Kudos! How did you choose a value for NK? What GPU utilization do you see in GPU-Z or similar, vs cpu utilization of the process in Task Manager (Win) / top (Linux)?

const int ntestprimes = 160;  // tweak as needed

This seems small to me. You may gain more performance by sieving out more candidate factors, with more known small primes.

Thanks! I choose NK, the chunk of work for each thread, to keep the time running on the gpu to around 150ms. Longer than that seems to make the console unusable. It seems to me that when a computer shader is running everything else waits. Still looking at this.

The cpu does basically nothing, mapping/unmapping memory, checking on 64bit result and setting K for the next round. The vulkan calls don't seem to need any overhead that I can see. It will max out my gpu at 250W if I let it go at 2200Mhz. (On linux)

You are correct, as it is now the sieve lets about 12% through. It should do better if it takes it down to around 8%, I think. But it doesn't at the moment. That function needs a little work to make it more pipelined, maybe.

Now, if someone had a fft/ntt based Square-mod function I could use... :)

[mrh]

With a few optimizations, it can test about 420M factors/second, or about 15 ghz-days/day (I think). Pretty good considering the really slow/simple squaring algorithm.