Modifying engine data

Changing data will have a cost. This cost can sometime be neglectable, and sometime not. All this depends on the kind of application considered of course. The purpose of this page is to provide a few details on REDsdk's internal mechanisms to handle data.

GPU updates

Any pure hardware mode or hybrid mode REDsdk application will have to deal with GPU updates on making changes to data. First of all, as detailed here: Transaction management, changes in REDsdk occur between a call to RED::IResourceManager::BeginState and a call to RED::IResourceManager::EndState. The call to RED::IResourceManager::EndState commits all changes and updates the GPU accordingly to reflect these changes.

Among the different possible changes that can occur, we'll mainly discuss:

And finally some Free GPU operations, that have zero cost!

Material GPU updates

On calling RED::IResourceManager::EndState, REDsdk will prepare all materials for the rendering. This implies a parsing of the modified material contents. This operation consumes some time by itself: around ~1/10th of a millisecond for complete materials with several rendering configurations. This time may of course vary with the number of RED::LayerSet configurations, the number of shaders involved and the number of RED::HARDWARE_PLATFORM to handle.

Image GPU updates

REDsdk does not have any image copy allocated on the CPU side. Therefore, at the time a pixel array is loaded for an image (using RED::IImage2D::SetPixels for example), it directly goes up to the video memory, without any pit-stop on the CPU side. Note that image operations are synchronous and should not be executed from auxiliary threads, as detailed here: Modifying images during a draw.

Geometry GPU updates

REDsdk clusters geometries together into large batches to reduce the number of rendering calls, per material, unless specified otherwise through RED::IMaterial::SetBatchMode. Therefore changing the contents of a single geometry may have an effect on a larger memory chunk than the one used by the geometry itself, alone.

Under certain conditions, REDsdk can do what is called a 'smart GPU update' where only the portion of the changed geometry is being modified. Whenever all conditions below are fulfilled, REDsdk can do a smart update on a geometry modification:

Other changes may cause a 'full GPU update' for the memory batch storing the geometry:

Text GPU updates

These rules apply to RED::ITextShape rendered with RED::IFont using the RED::FNT_TEXTURE display method:

Free GPU operations

To complete the list of operations detailed above, several scene graph operations have no effect at all on the GPU memory.

CPU updates

Of course, CPU updates are completely different from GPU updates. The point with CPU updates is all about the update of the acceleration structure used for the ray-tracing of the considered scene.

Unlike GPU updates, CPU updates are NOT performed during the RED::IResourceManager::EndState call. CPU updates occur during RED::IWindow::FrameTracing (or any FrameTracing derived calls). The acceleration structure gets updated first.

The general rule is that the amount of time needed to update the ray-tracer acceleration structure is directly proportional to the number of triangles that are modified in the structure. Any world space position change of a triangle (or line) is considered as a modification. Matrix transformations of instances are considered as changes applied to all the geometry being manipulated for the purpose of updating the acceleration structure.

CPU acceleration structure reset

On certain conditions, the acceleration structure of the engine may be reset:

CPU acceleration structure update

Updates occur (so this increases the total number of triangles or lines or points to update) on the following conditions: