SPS experiments

[jerome]

thanks for the feedback... I'm no shader expert, it's my first one ever. The message seems to tell us that Edge doesn't like my float array declaration : float[11] rotMatrix

not sure... I'll ask to the shader gods.

In order to better understand the comparisons between all these versions, the GPU one ( http://jerome.bousquie.fr/BJS/test/SPSGpu/spsShader.html ) is actually exactly the same than the monothreaded typed array based one ( http://jerome.bousquie.fr/BJS/test/spsBuffer.html ), except that the transformations are computed GPU side instead of CPU side.

This means that, without any worker, the gain is really important.

Compared to the worker versions, on my not-that-strong laptop, the GPU version is a bit faster than the worker version.

Should I add workers now to the GPU version ? not sure actually, because all the heaviest computation part is deported to the GPU and the CPU only does now simple array element assignements. Splitting the array among different workers won't bring anything more because the memory shared between these workers can't be also shared with the GPU, meaning that we have to loop over the whole worker shared array, once updated, to copy it into the GPU buffer anyway.. so the same loop size in final, once more, to fill the vertex buffer.

[Raggar]

Just as I'm reading about this tech, this thread pops up

The GPU version runs at 40FPS on my rig, and both the 2 latest worker versions run at 60FPS, although you can spot some slight stutter.

[jerome]

So maybe it's worth the try to add the worker to the GPU version and check ... I'll do it next week if I can.

[Raggar]

I honestly have no idea. I'm still trying to wrap my head around shared arrays and atomics, to see whether, and how much, these are usable for running physics in workers. Why not give it a try. At least you'll gain some knowledge. It's just a matter of time before it's as compatible as WebGL. I'll be interesting in your findings and experiments..

[Spankied]

I'm using an old office desktop and the final worker version was remarkably faster. Wasn't able to discern the ∞ symbol in previous versions cause was taking too long. 

[Convergence]

Since the security patch where SharedArrayBuffer was disabled, this doesn't work anymore

[jerome]

yes, AFAIK, because of Spectre/Meltdown everything related to shared memory is disabled everywhere (I think that it can be manually enabled though)

[jerome]

I just had an idea to make it work with the same efficiency without the (disabled) SharedBufferArray feature.

Not sure I'll have the time and the energy to implement it soon though

[jerome]

Let's go on now with the WASM SPS.

First remember the former tests on a 40 K solid particle SPS and the perfs I get in my Chrome :

Legacy SPS : http://jerome.bousquie.fr/BJS/test/spsReference.html     (8 fps)

Lighter Buffer SPS : http://jerome.bousquie.fr/BJS/test/spsBuffer.html   (7 fps)

Two worker SPS : http://jerome.bousquie.fr/BJS/test/SPSWorker/twoWorkers/spsProtoWorker.html (37-42 fps)

and now the WASM SPS : http://jerome.bousquie.fr/BJS/test/SPSWasm/spsWasm.html  (31 fps)

This last version has done with AssemblyScript like explained here :

It's the Buffer SPS version ported to AssemblyScript, then compiled in WASM. It brings a gain of 4.4 more speed

You can get the AS source here : http://jerome.bousquie.fr/BJS/test/SPSWasm/index.ts

Please let me know how this behaves in your browser.

Note that WASM is compatible with workers and that a double-worker-wasm SPS could be implemented... not sure I'll do it because it's quite complex.

[EDIT] : a test with 20K particles runs at 60 fps here. So I guess that a two-worker implementation, each computing 20K in wasm, could also run at 60 fps for a total of 40K particles.

[jerome]

let's also recap what dimensions we are talking about :

20 K boxes, each having 24 vertices = 480K vertices

+ 20K tetrahedrons, each having 12 vertices = 240K vertices

A total of 720 K vertices, knowing each has 3 floats (x,y,z)  for the positions and 3 floats for the normals, so 4.320 millions floats just for the coordinates.

Each particle stores a shape length, an integer, so 40K integers more.

Each particle is set a transformation (a position, a rotation and a scaling) so 9 floats per particle, so 360 K floats.

In total 4.680 millions floats and 40K integers as input data.

From these  input data, 4.320 millions floats, the transformed vertex positions and normals, are computed and stored in the same buffer... in 18 ms

[EDIT] and meanwhile 40K quaternions and 40K rotation matrices, one per particle, are also computed !

[Guest]

Really cool experiment!