This article explains different ways to update buffers and textures in Diligent Engine as well as important internal details and performance implications related to each method.

Buffers

Buffer Initialization

The most basic way to supply data into a buffer is to provide it at initialization time, for example:

Note that the contents of USAGE_STATIC buffers cannot be changed and initial data must be given at initialization. Initial data can also be provided for USAGE_DEFAULT buffers, but not for USAGE_DYNAMIC buffers that are updated through mapping. Use USAGE_STATIC buffer for data that never changes.

Updating buffers with IBuffer::UpdateData()

The first way to update a buffer contents at run time is to use IBuffer::UpdateData() method. Only buffers created with USAGE_DEFAULT flag can use this way. This method writes new data to a given buffer subregion, as in the example below:

Under the hood, Diligent Engine translates this call into the following operations:

OpenGL/GLES backend

The operation directly translates to glBufferSubData.

Direct3D11 backend

The operation directly translates to ID3D11DeviceContext::UpdateSubresource.

Direct3D12/Vulkan backend

Default buffers are allocated in GPU-only accessible memory, so the data cannot be written directly. To perform the operation, the engine first allocates temporary storage in a CPU-visible memory, copies the data to this temporary storage and then issues GPU command to copy the data from the storage to the final destination. It also performs necessary resource state transitions (such as shader resource -> copy destination).

Performance

IBuffer::UpdateData() is currently the only way to update data in a default (GPU-only) buffer. The operation involves two copy operations. However the main and not so obvious performance issue with this method is state transitions. Every time when a buffer is used in a copy operation, it needs to be transitioned to copy destination state. Every time it is used in a shader, it needs to be transitioned to shader resource state. Transitioning back and forth stalls the GPU pipeline and degrades performance dramatically.

This method should be used when a buffer content stays constant most of the time and only needs to be updated occasionally, usually no more often than once in a frame, for example, when reusing existing buffer to write new mesh data (vertices/indices). This method should not be used for high frequency updates such as animation or constant buffer updates.

Limitations

Inefficient for frequent updates.

Updating Dynamic Buffers via Mapping

When buffer contents needs to be updated frequently (once or more times per frame), the buffer should be created with USAGE_DYNAMIC  flag.  Dynamic buffers cannot be updated with IBuffer::UpdateData() . Instead, they need to be mapped to obtain a pointer that can be used to write data directly to the buffer, as in the example below:

OpenGL/GLES backend

The operation translates to glMapBufferRange with GL_MAP_WRITE_BIT and GL_MAP_INVALIDATE_BUFFER_BIT flags set.

Direct3D11 backend

In Direct3D11 backend, this call directly translates to ID3D11DeviceContext::Map with D3D11_MAP_WRITE_DISCARD flag.

Direct3D12/Vulkan backend

When dynamic buffer is created in Direct3D12 or Vulkan backend, no memory is allocated. Instead, both backends have special dynamic storage which is a buffer created in CPU-accessible memory that is persistently mapped. When dynamic buffer is mapped, a region is reserved in this buffer. This operation boils down to simply moving current offset and is very cheap. A pointer is then returned that references this memory and the application can write data directly, avoiding all copies. When a dynamic buffer is used for rendering, internal dynamic buffer is bound instead and the proper offset is applied. Internal dynamic buffer is pre-transitioned to read-only state and no transitions are ever performed at run time. The engine takes care of synchronization making sure that a region in the buffer is never given to the application while being used by the GPU.

Performance

In Direct3D12/Vulkan backends mapping dynamic buffers with MAP_FLAG_DISCARD flag is very cheap as it only involves updating current offset. It is hard to say what exactly Direct3D11 and OpenGL do under the hood, but most likely something similar. There is one significant difference however: Direct3D11 and OpenGL preserve contents of dynamic buffers between frames while Direct3D12 and Vulkan backends do not. As a result, mapping is many times more efficient in next-gen backends.

Dynamic buffers should be used for content that changes often, typically multiple time per frame. The most common example is a constant buffer that is updated with different transformation matrices before every draw call. Dynamic buffers should not be used for constant data that never changes.

Limitations

Only the entire buffer can currently be mapped with MAP_FLAG_DISCARD flag.

In Direct3D12 and Vulkan backends, the contents of all dynamic resources are lost at the end of every frame. A dynamic buffer must be mapped in every frame before its first use.

The total amount of CPU-accessible memory can be limited. Besides, access from the GPU may be slower compared to GPU-only memory, so dynamic buffers should not be used to store resources that are constant or change infrequently.

Streaming Buffer

Streaming buffer is not an API object, but rather a strategy that allows uploading variable amounts of data to the GPU in an efficient manner. The idea of streaming buffer can be summarized as follows:

• Create dynamic buffer large enough to encompass the maximum amount of data that can be uploaded to GPU.
• First time, map the buffer with MAP_FLAG_DISCARD flag.
  • This will discard previous buffer contents and allocate new memory.

  A relationship cannot be happy, if it lacks the get levitra sexual pleasure. Never take more than one tablet of http://appalachianmagazine.com/category/history/old-ways-memories/?filter_by=popular cheapest levitra a day is enough. What is Sildenafil Citrate? Sildenafil Citrate is a drug that was invented to treat erectile dysfunction effectively and with a discount bulk viagra significant improvement in the quality of life. The medical experts in France and from other countries are researching on regulating viagra online Dosage and Prices hormones in a patient with chronic pancreatitis usually come together with deficiency of the magnesium.

• Set current buffer offset to zero, write data to the buffer and update offset accordingly.
• Unmap the buffer and issue draw command.
  • Note that in Direct3D12 and Vulkan backends, unmapping the buffer is not required and can be safely skipped to improve performance.
• When mapping the buffer next time, check if the remaining space is enough to encompass the new polygon data.
• If there is enough space, map the buffer with MAP_FLAG_DO_NOT_SYNCHRONIZE flag.
  • This will tell the system to return previously allocated memory. It is the responsibility of the application to not overwrite the memory that is in use by the GPU.
  • Write new data at current offset (which guarantees that bytes previously written and currently used by the GPU will not be affected) and update the offset.
• If there is not enough space, reset the offset to zero and map the buffer with MAP_FLAG_DISCARD flag to request new chunk of memory.

Textures

While buffers are simply linear regions of memory, textures are optimized for efficient sampling operations and use opaque layouts that are typically not exposed to the application. As a result, only the driver knows how to write data to the texture. Linear texture layouts are allowed in Direct3D12 and Vulkan, but they are less efficient.

Texture initialization

Similar to buffers, initial data can be supplied to textures at creation time. For USAGE_STATIC textures this is the only way.

Updating textures with ITexture::UpdateData()

The first way to update textures is to use ITexture::UpdateData() method. The method works similar to IBuffer::UpdateData() and writes new data to a given texture region:

OpenGL/GLES backend

The operation directly translates to glTexSubImage** family of functions.

Direct3D11 backend

As with buffer updates, in Direct3D11 backend, this call directly maps to ID3D11DeviceContext::UpdateSubresource.

Direct3D12/Vulkan backend

As with buffers, to update a texture the next-gen backends first allocate region in a CPU-accessible memory and copy client data to this region. They then perform necessary state transitions and issue GPU copy command that writes pixels to the texture using GPU-specific layout.

Performance

Usage scenarios are similar to buffer updates: the operation should be used for textures whose contents stay mostly constant and only occasionally requires updates.

Limitations

As the operation involves two copies and state transitions, it is not efficient for frequent texture updates.

Mapping textures

Mapping a texture is a second way to update its contents. From the API side, mapping textures looks similar to mapping buffers:

What happens under the hood is very different compared to buffers.

OpenGL/GLES backend

Mapping textures is currently not supported in OpenGL/GLES backends.

Direct3D11 backend

In Direct3D11 backend, this call directly maps to ID3D11DeviceContext::Map with D3D11_MAP_WRITE_DISCARD flag.

Direct3D12/Vulkan backend

There are no dynamic textures in next-gen backends in a way similar to dynamic buffers. While buffers can easily be suballocated from another buffer by binding parent buffer and applying an offset, there is no similar way for textures. So even if the required memory was suballocated from the dynamic buffer, there would be no way to treat this memory as a texture. Binding the memory to an existing texture is also not allowed. As a result, mapping textures in Direct3D12/Vulkan backend does not differ significantly from updating textures with ITexture::UpdateData(). When mapping a texture, the engine returns the pointer to the CPU-accessible memory directly that avoids one copy. However, GPU-side copy and most importantly state transitions are still performed.

Performance

It is not exactly clear what Direct3D11 does under the hood. The two most likely options are either creating linear-layout texture and suballocating it from CPU-accessible memory every time Map is called, or performing the same operations as Diligent’s next-gen backends.

Mapping dynamic textures is not as efficient as mapping dynamic buffers, and typical usage scenarios are similar to ITexture::UpdateData().

There is no simple way to implement high-frequency texture updates across all APIs, so Diligent expects that this will be implemented by the application using low-level API interoperability.

Limitations

Texture mapping is not currently implemented in OpenGL/GLES backend.

In Direct3D11, only the entire texture level can be mapped with D3D11_MAP_WRITE_DISCARD flag.

In Direct3D12/Vulkan backends, mapping dynamic textures is not as efficient as mapping dynamic buffers. In fact, it is very similar to updating textures with ITexture::UpdateData() and only avoids one CPU-side copy.

Summary

The following table summarizes update methods for buffers:

The following table summarizes update methods for textures:

 

The following tutorials illustrate the ideas described above:

Tutorial 10 – Data Streaming

Tutorial 11 – Resource Updates