Bekas:

I have little knowledge about the TPT architecture, i just pointed out the drawbacks of the openCL.

However if there is a pratical solution probably multithreading.
But like Simon said

 

 The main issue with multithreading the simulation is memory access

What I meant by double buffering, is creating an inmemory copy of the frame after its processed, which the drawing routine can access. Creating a copy uses less time than to synchronise the logic and draw with each other.

@plypencil (View Post)

plypencil:

 

 What I meant by double buffering, is creating an inmemory copy of the frame after its processed, which the drawing routine can access. Creating a copy uses less time than to synchronise the logic and draw with each other.

I tried creating a copy of the data and updating the particles based on that data.
The data that i duplicated was the parts array.
Still i got particles beeing 'randomly' killed

@plypencil (View Post)

 I don't know if you really get double buffering. Double buffering is actually holding two memory buffers, and then only drawing to one, while the offer is being displayed. The advantage is that you only swap buffers when you are finished drawing, so the screen doesnt display the updates until they are finished. Nothing to do with copying.

If you have each thread modifying a separate buffer, well, you have accomplished nothing, as you have to sync the buffers. If each modifies the same buffer and they are flipped, what does this accomplish? You still have shared memory issues.

I think what @plypencil was trying to say is to use an array with the data before the update. And let the threads acess that array to update the 'original' one.
While this does work for some applications ( like CA ), it cant be applied to PT.

Really, after profiling powder, and looking at the relevant code, TPT was just not designed from the ground up to be multithreaded. The simulation update code takes 40% of all cpu time, and the biggest issue I saw looking at the code (if I understood it correctly), is that particles are updated in a very specific order. Threading this so that multiple particles are updated at once (the only real way multithreading could help) could create all sorts of obscure changes in certain saves, if they worked due to particles updating in a sequential order. I do plan on trying it anyway in my free time just to see what happens, but there is not really much hope that it won't break terribly at this point.

mniip:

heat simulation works on a proprietary engine which was optimised in all possible ways, the most lagging part is update functions, which are called tons of times, you can't do anything with it

 Wait, proprietary? I thought it was based on FFTW, unless I have absolutely no idea what I'm talking about :(

So, Optimizations are possible, but not quite to the extent of multi-threading. Ok, This is fine.