HydraX Performance and Threading

I've been looking at improving the performance of HydraX.
I've basically taken these steps:-
1) Start with the community hydrax project:
viewtopic.php?f=20&t=29704
2) Add the available performance fixes:
viewtopic.php?f=20&t=13510
3) Thread the calculation performed in the projected grid module:
viewtopic.php?f=20&t=11691
4) Optimize loops where possible

These changes have given mixed improvements (these figures are using the default settings with non-GPU processing on a relatively fast CPU/GPU) :-
102 FPS baseline with none of the above changes made.
987 FPS when camera is static
175 FPS when camera is moving

As the above figures show the performance gain for a static (non-moving camera) is considerable (9x). However when the camera is moving the frame rate drops (1.7x). This is due to how much recalculation of the projected grid is required when the camera moves.

I may be able to increase this frame rate a little by using camera listeners to start the recalculation as soon as the frame starts rather than when Hydrax gets notified. However, I am wondering if there is a reasonable way of altering the projected grid algorithm for camera movement (adding skirts perhaps). Or if the best approach is actually to write a less efficient but easier to thread geo-mipmap module for Hydrax.

Any thoughts/musings welcome...

Hi there, it's so seldom I check these forums but I noticed this post just now.

Personally, I don't think there is much of a gain to be made threading out the calculation of the projected grid. Since the grid relies on the camera position/orientation, you need the calculations to be in lockstep with rendering or else you run the risk of rendering a frame with the grid out of alignment. So in the end, the rendering thread would have to wait for the grid calculation thread results ... so yeah you could make a bit of gain depending on how much else you are doing with the rendering thread between frames, but it's not going to be too much in my opinion. Skirting as you mention sounds like a promising solution to that, since you could then eliminate the requirement of the render thread waiting for the grid thread and (in most cases) the grid will be aligned enough. There would always be the case where the camera orientation/position changes so drastically the skirt doesn't cover it, but I imagine you could develop skirting that covered most cases.

Of course, just updating the noise in a thread is an excellent gain and I have done so in my own projects.

Personally, I don't think there is much of a gain to be made threading out the calculation of the projected grid.
I completely changed my mind about this, in case anyone actually reads these threads haha. I had been using hydrax with low mesh complexities on devices without much threading potential. If you had large complexity meshes you definitely could benefit even from synchronous threading and splitting up the task of generating the projected grid (eg using a thread barrier).