How can we update acceleration when we want or in parallel?

Hi,

We have started looking to design a new renderer using OptiX and what we have learnt from our research task. One things we are interested in is the possibility to have better control over when accelerations structures are calculated. Part of the idea is to possibly have a process that just generates acceleration structures in the background as a worker.

The principle idea is that we could load in complex geometry and calculate the acceleration over multiple frames without affecting the next launch so rendering remains realtime however much happens in the frame. When the acceleration is complete we then copy the data into the rendering scene. The only side affect is that a model will appear a couple of frames late. Or for the case of character animation the updated character pose would be calculated in parallel with the rendering of the previous frame so removing the serial nature of acceleration-update followed by render.

The only way we can currently see achieve this at present is via a second Context which has a sole task of updating accelerations structures. We then get the acceleration caches and put them into the rendering context along with setting/switching out the geometry buffers which would be passed using simple CUDA interop so requiring gpu-gpu or no copy at all.

There are a couple of issues with our multi-context idea though:

  • To copy the acceleration data it has to go via host memory so wouldn’t be as fast as technically possible.
  • The acceleration context is still going to ‘compile’ when we do launch(0) which is redundant
  • We will essentially double-buffer character geometry and swap the buffers which could cause some problems in OptiX?

Any views on how we could have control over some acceleration-build scheduling with the single or multi-context or other methods would be greatly appreciated. We see that OptiX is getting faster and faster builds so is it the view of the OptiX team that builds will remain automatic for foreseeable future?

Cheers,
Craig

OptiX ASes are undergoing a heavy re-engineering process to increase performances but that isn’t involving what you wrote right now. Using a worker thread would require not using GPGPU capabilities. Otherwise more complex mechanisms should take place.

Just to ask: are you already using fast building ASes right? If your primary goal is real time speed that should be mandatory

Thanks mark, great to hear optimizations are being made. We are very aware there are fast building ases and are currently back in the designing phase where we are trying to avoid the issues that can occur even if all the builds were blindingly fast. We are thinking of larger environments with many deformed models instead of the sandbox sort of demo case. The simulation in question has over 600 characters and vehicles in view at any one time and the database is of a large country. When paging a larger environment it would be great to be able to have a thread generating the high quality acceleration separate to the rendering. The fast stuff may be fast but if the scene already has a large number of moving characters there might not be enough time remaining to do this processing in the current serial manner. Hence we were thinking up ways we could manage the acceleration builds so we could prioritize the load.

To clarify if all the moving stuff in a scene was taking 4ms and render was taking 10ms and we were aiming for 60Hz render. If we then wanted to add in a new set of geometry, this new geometry is going to take 3ms to calculate. This therefore takes us over the 16ms (4+10+3=17) and we drop a frame. However if we had started calculating but not waited for it to complete (or paused build) we would have been able to finish the calculation by the next frame without a hitch.