JoeJ said:
If you test un C++ side, does that mean you have the same implementation in C++ as in CS? If so, why don't you finish your project with C++ alone, and after this works port back to CS? Much less than half work, more than conpensating the longer wait on processing.

When i was starting, I tried to run one minimal part of the task in JS. IIRC i had to use workers or it was hanging. And after waiting 30 minutes for it to finish and did not finish yet, i closed it. This depressed me in that moment.

Then i briefly, superficially made some tests in C++ and it was too slow again. I did not see it finish, closed the exe. It was a superficial approach to the algorithm just to test and C++ did not finish. So i decided to go for the GPU.

Now that i think it, while optimizing for the GPU, i optimized the algorithm too.

And i can not tell now if i use the optimized algorithm on the CPU again, will finish in time. That old bad algorithm was no-go for the CPU. That is sure. But i don't know about the new algorithm.

Sometimes we fall victims of the situation. Now that i invested too much work in shaders is hard to throw it all away. It constantly looks like i am just two days away from finishing the damn shader and some bug pops up…

If you work two years on shaders, and i gift you a motherboard with 4 top tier Xeon CPUs, would you throw two years of work away? It is the better thing to do if the new hardware allows it. But would you do it? It is two years of your life.

(The tests that run on C++ are not repeating all of the functionality. Just a little bit. Only these methods and places, i consider to be the most error-prompt.)

(Now you injected an obsessive doubt in my mind about if the latest optimized algorithms would be fast enough for the CPU. Most probably still too slow. But "what if"….)

@SuperVGA I think now, i should copy paste the code from HLSL to C++. Having it running after the rephrased code. And then compare the two results coming from C++, one rephrased and other copy pasted.

This started to sound insane to you…. let me explain - inside HLSL, it is faster(in my case, not recommending to nobody to do this) to merge two nested “for” loops into a single "while" loop. I hope it makes more sense now for you my practice of rephrasing the code.

C++:
for (n < 256) {
for (m < 256) {
var = bimbam(n, m)
}
}

HLSL:
while (counter < 256 * 256) {
var = bimbam(counter >> 8, counter & 255)
counter++;
}

I think i will copy-paste the "while" version under the "forfor" inside C++ and run it the both ways, and compare the results.

Ok, stopping here. Started sounding crazy…

NikiTo said:
If you work two years on shaders, and i gift you a motherboard with 4 top tier Xeon CPUs, would you throw two years of work away? It is the better thing to do if the new hardware allows it. But would you do it? It is two years of your life.

If that other hardware is faster or easier to develop on, i would do it.

Because nothing gets lost.

Sure CPU can't do parallel programming model of CS, but you can port still, and keep the parallel model in mind. Worked well for me, although i did it only the other way around.

NikiTo said:
The tests that run on C++ are not repeating all of the functionality. Just a little bit.

Well, then i'm not sure if it's worth to do the port. It depends. If you are confident shaders are proper and won't change, keep them ofc.

It's just that your stuff is so extremely slow, i'm 100% sure it could be made faster. But you prefer to have… superpowers ; )

Why all that ‘testing' all the time?
Together with prem.optim, it always feels more like ‘prolonging because i'm unsure what's next’, than just some bad habit?

Premature optimization from the mental ancient people -

The easier and more productive way to do it -

Definition of overdoing it -

The logical thing to do -

Conclusion - I am an Ancient Alien.

You need to go back a long time to find excuses!

So what i'm heading to is: Stop polishing, start work on the next step ASAP (maybe not on GPU).

Because often when working on next step, it turns out the former step could have been less perfect, and former polishing work becomes obsolete afterwards.
The lesser precisely defined next step is, the more likely this happens. …as i've learned the hard way.

In the end you get perfect result even if ‘doing the easier way’. Proof:

see? they did it too!

How did you see that???????

Kudos!! This means i am an Ancient Alien Time Traveler.

I googled “C# GPU”. Seen only Cuda stuff.

“Hybridizer Software Suite: enables CUDA, AVX, AVX2, AVX512 targets and outputs source code. This source code can be reviewed, …” Sounds great. BUt still not convinced. I should have gone for it before touching HLSL. Now that i know HLSL, it is not tempting me.

I consider dedicating this whole month to writing a parser in C# that will generate the HLSL source code for me. This will save lot of time once done. I think this is the most elegant thing a programmer should do. Like Geri said. But it will be simple not optimized C# at all. Would use the regular string, not the faster string builder of C#. Super slow code. Still would parse generate my HLSL pretty fast. No need for a single bit of optimization here.

If my HLSL were standard, i should use Hybridizer. But my HLSL is peculiar, so an elegant thing for a programmer to do is to program a small tool to use.

And something installed Python on my PC without asking me(EDIT: the programing GUI too). I think this could be a sign from the destiny. I could introduce myself to Python and TensorFlow during the breaks. Now, during the breaks i am doing something on blender to relax. I could play with TensorFlow instead. This way the switch to ML would be smooth. Would not feel like “i throw it all to start new”. I could install Unity for the AI agent too. I hope tensorflow is not gonna ask me to download half of the internet in libraries and dependencies. Never installed it before.

NikiTo said:
Hybridizer Software Suite

Found a lot such stuff with googling ‘c# to HLSL compute transpiler’

@JoeJ I feel like for the same time i read their documentation and learn their notations, i would already have my own tool running. Just need to keep coding it. And i could publish my tool on github for other peopel to use and read my documentation.

I call this - “to eat from the hand of somebody”. If the publisher decides to cancel the tool i am toolless. If i make my own tool, i am independent. It is not something so hard to do.

Yeah, i would agree to that. At first…
It's a lot of work i think. Need to handle LDS, not to mention parallel execution. I would end up hacking some kind of pragmas into comments, probably. And my result would be much too messy to release it.

It just sucks. OpenCL really is easy to use in comparison, but can't rely on AMD to keep it up. They already dropped CPU support for it. And even it runs on CPU too (using Intel lib or deprecated AMD), you can not debug so easily. So that's no real alternative worth to consider.

If i discuss with people, everybody recommends Cuda. IDK how much more productive this is, what difference it would make.

MS AMP was easy too (although too high level to be really fast), bit AFAIK that's pretty mach gone as well.

Then there is Intel building up this: https://software.intel.com/content/www/us/en/develop/tools/oneapi/data-parallel-c-plus-plus.html​
Their

… totally buggy again this form. >;(

Intels stuff seems awesome, but thy have just started, and not much of a GPU yet.

I recommend you try an existing transpiler tool first. If it works well, fine. If it vanishes, you still have both versions of code, and you can make your own at any time.