10-15% Speedup by enqueuing more at a time

https://github.com/ProjectPhysX/FluidX3D/blob/584f10a382b47cdec5972bcae27bbc83a8c70b23/src/lbm.cpp#L851

Tested on 2D Taylor Green Vortex

By default, I get something around 2400-2500 Steps per Second. I'll use 2490 as my starting FPS.

I added the following simple modification.

	for (uint d = 0u; d < get_D(); d++)
	{
		for (uint step = 0; step < 4; step++) {
			lbm_domain[d]->increment_time_step();
			lbm_domain[d]->enqueue_stream_collide(); // run LBM stream_collide kernel after domain communication
		}
		
	}

This enqueues 4 steps at a time, before doing a blocking synchronization step.

On my PC, this now will show me as having 692 Steps/s, which multiplied by 4, is 2768 (since the machine is confused due to the domain running 4x steps when the output is only expected 1).

2768/2490 is just about 11% speedup.

You can enqueue more at a time, say 100 steps per iteration.

Now the output says it's 29 Steps/s implying it's running at a slightly faster 2900 FPS. (16% speedup). The downside however is now you're probably only rendering just under 30 FPS (at 100 *29 steps per second) instead of 60 FPS.

Probably an ideal solution would be to dynamically change the number of steps enqueued whenever the FPS is above 60.

Edit: Make sure you remove the lbm_domain[d]->increment_time_step(); that's called after synchronization to keep the timestep count correct.

Start at src/lbm.cpp around line 851 and inspect the surrounding synchronization, increment_time_step, and enqueue_stream_collide flow. Reproduce the Taylor Green Vortex benchmark, compare different enqueue batch sizes, and verify that timestep counts remain correct after synchronization. Done means a measured speedup without reducing rendering below the intended frame rate.