chipStar VS FluidX3D

There is already a work-in-progress implementation of HIP on top of OpenCL https://github.com/CHIP-SPV/chipStar and the Mesa RustiCL folks are quite interested in getting that to run on top of Vulkan.

chipStar (formerly CHIP-SPV) might also be worth checking out: https://github.com/CHIP-SPV/chipStar

It compiles CUDA/HIP C++ to SPIR-V that can run on top of OpenCL or Level Zero. (It does require OpenCL's compute flavored SPIR-V, instead of graphics flavored SPIR-V as seen in OpenGL or Vulkan. I also think it requires some OpenCL extensions that are currently exclusive to Intel NEO, but should on paper be coming to Mesa's rusticl implementation too.

Regarding the second item (CUDA to OpenCL), have a look at hipstar: https://github.com/CHIP-SPV/hipstar

Could even use this as a revers GLOBAL ORBITING SYSTEM [GoS] - Whereby a single satellite|probe dispels a lander to a planet with the Quantum Magnetic Cannister, and that QMC signals its global location to the satellite launcher, and the satellit can extrap its location based on the absolute location of the ground guys... (might need more than one ground magnet-moles?)

How can this be measured? Can fluidx3d do martian magnetics? [0]

--

[0] https://github.com/ProjectPhysX/FluidX3D

---

EDIT: "Mars does not have a magnetosphere"

ELI5: "how do electronics work when there is zero magnetic field around them? A complete antimagnetic environ?"

I've never heard any mention about making any electrical device work on a planet (such as mars) in a complete magnetically dark location?

How is there gravity on mars if there is no magnetic field for a planet, and how can mass, the size of a planet not produce magnetism/gravity if its not made of iron-sh (the RED of the planet)

ELI5, please.

See my post in this thread about dimples/barnacles...

But have you seen this guys package: https://github.com/ProjectPhysX/FluidX3D

Yes, I've made that super easy. You can change the VRAM capacity of your hardware as one number in the setup script and it will automatically scale the simulation up or down. See the documentation for details.

Also see this GitHub Issue on the problem: https://github.com/ProjectPhysX/FluidX3D/issues/59

If you want to play with the software yourself, FluidX3D is on GitHub: https://github.com/ProjectPhysX/FluidX3D

This is my opinion about what is happening. Production CFD solvers are really complicated and take a lot of time and energy to write. Engineers learning to use a CFD solver to get a job done is really time consuming and there are all sorts of issue that come up like actually trusting the new solver. Both of these things have really held back GPUs in this area. There are really only two ways out of this, either you write a solver from scratch and get people to adopt it (double hard) or you take an existing solver and modify it to run on GPUs (still pretty hard). The first option is very hard but ultimately the way to go in my opinion. The second option results in very poorly optimized GPU code and honestly just gives a bad name to GPU computing in my opinion. Take OpenLB for example, https://www.openlb.net/show-cases/highly-resolved-nozzle-simulation-performed-using-multi-gpu-support/. Terrible terrible performance compared to what you could get if you wrote the solver from scratch on the GPU, for example, https://github.com/ProjectPhysX/FluidX3D.