FLAMEGPU / FLAMEGPU2-visualiser

Cross platform real-time OpenGL visualiser for FLAMEGPU2 models.
1 stars 2 forks source link

Linux Visualiser Initialisation threading #3

Closed ptheywood closed 3 years ago

ptheywood commented 4 years ago

Under linux it appears that if a small number of steps are specified (i.e. -s 5) then the flame simulation completes before the visualisation is fully initialised, and therefore it does not work.

Initialisation should be blocking: the simulation should not start until the visualisation is fully initialised.

Additionally, If the visualisation is closed in visualisation more the simulation should end (IMO), at least if no iteration count is specified.

With -s 1

./bin/linux-x64/Release/circles_spatial3D -s 1
Arial,sans-serif ? /usr/share/fonts/truetype/croscore/Arimo-Regular.ttf
Font /usr/share/fonts/truetype/croscore/Arimo-Regular.ttf was loaded successfully.
Loading Model: icosphere.obj [Complete!]                            
Warning, material default shader is null.
Exported model /home/ptheywood/code/flamegpu/flamegpu2_dev/build/bin/linux-x64/Release/resources/icosphere.obj.sdl_export
Model 'resources/icosphere.obj' export was updated.
Warning, material default shader is null.
100.00% Drift correct
50.00% Drift correct
terminate called after throwing an instance of 'VisAssert'
  what():  /home/ptheywood/code/flamegpu/FLAMEGPU2_visualiser/src/Visualiser.cpp(114): Visualiser::run(): SDL_GL_MakeCurrent failed!

Aborted (core dumped)

With -s 5 my GPU appears to lock up for a while, with no SDL window appearing before the 5 (actually 10 steps for circles_3d) has completed.

Under debug builds, the SDL windows does appear, but instancing data is missing from the visualisation as the sim has already finished.

Robadob commented 4 years ago

As discussed away from GitHub, I couldn't reproduce these on Windows.

Under debug builds, the SDL windows does appear, but instancing data is missing from the visualisation as the sim has already finished.

This isn't what I thought it was. At the end of each sim step, the instancing data should be updated (it uses mutex to avoid race conditions). So I'm not actually sure of the cause, as the buffers should be upto date.

Additionally, If the visualisation is closed in visualisation more the simulation should end (IMO), at least if no iteration count is specified.

My assumption was that it would, but I guess I didn't think it through.

Edit: Fixed in branch initial_interface as of dbcac41

Robadob commented 3 years ago

From rediscussing this in slack. The problem is that the Sim requests buffer resize, and sends buffer updates until the sim ends. The vis for whatever reason is being very slow initially, and doesn't actually resize the buffers until the sim has already ended and finished sending it's buffer updates (which are therefore all ignored).

The solution being for the sim to have a better understand of whether the vis is ready to render before sending it's first data update. This will require an additional method adding to the vis interface, to return whether the render loop has begun (or first buffer resize has been received?) permitting data updated to be sent.

ptheywood commented 3 years ago

As an (incorrect) fix, moving the call to cudaSimulation.initialise to before visualisation.activate appears to lead to the expected behaviour (just posting for future reference before i discared my local changes). This may be required for #26, or atleast relevant.

Robadob commented 3 years ago

The branch wait_for_vis in both repos has my attempted fix.