3 ms·

The idea to put input energy via the mouse is nifty. Nice work! I dont think vertex buffers are the ideal storage mechanism for lattice methods. I used Cuda to

The idea to put input energy via the mouse is nifty. Nice work! I dont think vertex buffers are the ideal storage mechanism for lattice methods. I used Cuda to rasterize a plain buffer but I have two GPUs, the one doing the sim wasn't the one rendering. Its better this way if you are looking to run the sim 1000s of cycles per sec, but only render 60 fps. Theres a lot of extra data that could be eliminated by simply using a linear block of memory versus a vertex buffer. Depending on the goals for the sim, efficient rendering should be a lesser priority than efficient simulation speed. Here are two very similar frameworks I made for exploring parallelizable lattice sims: https://github.com/churchofthought/HexagonalComplexAutomata https://github.com/churchofthought/HexagonalComplexAutomata https://github.com/churchofthought/ScatterLife https://github.com/churchofthought/ScatterLife (Note: the video is of a skewed version due to hexagonal lattice coords - this is fixed in the latest commits) To OP, you may enjoy the study of transformation between Cellular Automata and Partial Differential Eqs. The PDF below is a gem, a good introduction to the techniques that will allow you to take any reasonable PDEs and produce CAs that produce equivalent dynamics: Cellular Automata, PDEs, and Pattern Formation https://drive.google.com/file/d/13cT_BU8LAaUK4KTYFfhVSpCVCmrWCkDA/view?usp=drivesdk https://drive.google.com/file/d/13cT_BU8LAaUK4KTYFfhVSpCVCmr...

akr 8y ago
(Author here) Thanks for the interesting links! I agree that there is much that could be optimized. The choice to use vertex buffers was driven by the overarching goal of implementing the whole thing in GLSL. It really is just a small playground project to generate some nice visualizations. If we wanted to actually use the results beyond displaying them the tight coupling between simulation and rendering would certainly become a hindrance. CUDA usage as you describe definitely seems to be the way to go for larger scale stuff. i.e. most GPU-based LBM codes that are actually used in research seem to be based on it.
- goldenkey 8y ago
  Well it looks awesome, we all are just fooling around with this stuff :-) If you did want to increase performance, you could try to use OpenGL for rendering but write your actual sim in CUDA C++. The whole interop API is listed here: https://docs.nvidia.com/cuda/cuda-runtime-api/group__CUDART__INTEROP.html#group__CUDART__INTEROP https://docs.nvidia.com/cuda/cuda-runtime-api/group__CUDART_... Essentially it wouldn't involve any host/memory transfer, all would be processed on GPU. Then you could limit your rendering thread to 60fps while running the CUDA kernel non-stop. I haven't actually tested this out though because I had 2 GPUs for the sims above, and the beefy one running the sim was on TCC instead of WDDM mode (no attached display allowable.) [1] So I had the universe state buffer transferred to host memory, and then to the 2nd GPU for rendering to attached display. I am not sure of the speed gains TCC vs WDDM really provides, but Nvidia says it makes "some difference." [1] https://docs.nvidia.com/gameworks/content/developertools/desktop/nsight/tesla_compute_cluster.htm https://docs.nvidia.com/gameworks/content/developertools/des...

akr 8y ago

(Author here) Thanks for the interesting links! I agree that there is much that could be optimized. The choice to use vertex buffers was driven by the overarching goal of implementing the whole thing in GLSL. It really is just a small playground project to generate some nice visualizations. If we wanted to actually use the results beyond displaying them the tight coupling between simulation and rendering would certainly become a hindrance. CUDA usage as you describe definitely seems to be the way to go for larger scale stuff. i.e. most GPU-based LBM codes that are actually used in research seem to be based on it.

goldenkey 8y ago
Well it looks awesome, we all are just fooling around with this stuff :-) If you did want to increase performance, you could try to use OpenGL for rendering but write your actual sim in CUDA C++. The whole interop API is listed here: https://docs.nvidia.com/cuda/cuda-runtime-api/group__CUDART__INTEROP.html#group__CUDART__INTEROP https://docs.nvidia.com/cuda/cuda-runtime-api/group__CUDART_... Essentially it wouldn't involve any host/memory transfer, all would be processed on GPU. Then you could limit your rendering thread to 60fps while running the CUDA kernel non-stop. I haven't actually tested this out though because I had 2 GPUs for the sims above, and the beefy one running the sim was on TCC instead of WDDM mode (no attached display allowable.) [1] So I had the universe state buffer transferred to host memory, and then to the 2nd GPU for rendering to attached display. I am not sure of the speed gains TCC vs WDDM really provides, but Nvidia says it makes "some difference." [1] https://docs.nvidia.com/gameworks/content/developertools/desktop/nsight/tesla_compute_cluster.htm https://docs.nvidia.com/gameworks/content/developertools/des...