With Xbox One, CPU access to DEFAULT usage resources is opened up beyond that of standard D3D11. Standard D3D11 semantics only allows CPU access to DYNAMIC and STAGING usage resources. DYNAMIC and STAGING usage resources are used to pass data between the CPU and GPU, but these resources have important restrictions that limit their usefulness and impose certain semantics on the driver that are not always the best for performance. Ease and convenience of DYNAMIC usage resources are counterbalanced by the complexity and high overhead of the driver resolving which rename buffer is active at various points in time.
In contrast, with D3D11 on Xbox One, CPU access to DEFAULT usage resources is opened up. DEFAULT usage resources are single buffered; one allocation per resource, and with no renaming. DEFAULT resources can be read and written by the GPU, and on Xbox One, read and written by the CPU as well. They are similar to STAGING resources that have more flexible GPU access, rather than single buffered DYNAMIC usage resources.
The title can take control of multiple buffering. Instead of working with a single DYNAMIC resource whose renaming is an opaque driver detail, DEFAULT usage resources can be created in the quantity needed by the developer, and the title is responsible for implementing the proper round-robin sequencing to avoid CPU stalls.
One good use of this functionality is the usage of Constant buffers, and other dynamic data that is generated or updated on the immediate context, but used on deferred contexts to record command lists. Usage of externally-updated DYNAMIC usage resources on a deferred context causes a split point to be generated in the command list, because the correct rename buffer for the resource is not known until the method ID3D11DeviceContext::ExecuteCommandList is called. A specific DEFAULT usage resource selected from a round-robin pool can be updated on the immediate context and can also be loaded into the deferred context recording for that same frame. This process should be much more efficient in terms of CPU overhead.
The application of DEFAULT usage is shown with the following example code; updating a resource during frame rendering:
ID3D11Buffer* pCurrentCBVertex = m_pCBVertex[ m_FrameIndex % ARRAYSIZE(m_pCBVertex) ];
D3D11_MAPPED_SUBRESOURCE MapData = {};
m_pd3dContext->Map( pCurrentCBVertex, 0, D3D11_MAP_WRITE_NO_OVERWRITE, D3D11_MAP_FLAG_ALLOW_USAGE_DEFAULT, &MapData );
CBVertex* pVSData = (CBVertex*)MapData.pData;
XMStoreFloat4x4( (XMFLOAT4X4*)&pVSData->Transform, matWVP );
m_pd3dContext->Unmap( pCurrentCBVertex, 0 );
The Map call uses the D3D11_MAP_FLAG_ALLOW_USAGE_DEFAULT flag. To Map a DEFAULT usage resource, this flag must be specified. The map type used is MAP_WRITE_NO_OVERWRITE; the allowed map types for DEFAULT usage resources are the following:
MAP_WRITE_NO_OVERWRITE is implemented as MAP_WRITE, but without checking for CPU-GPU synchronization. To avoid a CPU stall, use the MAP_WRITE_NO_OVERWRITE flag with caution. The other three map types perform proper synchronization checks before returning the CPU pointer; this synchronization could result in a CPU stall if the resource is still in use by the GPU.
When Map or Unmap are called, no CPU cache flush is done. If the resource was created with cached noncoherent memory (that is, initial contents were provided), a CPU cache flush is required before reading or after writing, as well as a GPU cache flush after CPU writing.
The title can create placement resources with DEFAULT usage, and then map them for CPU access using this functionality. In this case, the driver has no concept of what type of memory is being used. The title is responsible for proper cache invalidation in this case. The safest thing for a title to do is to use cache-coherent memory in all cases where the title needs CPU access and is not GPU bandwidth-bound on reading or writing the DEFAULT usage resource in question.
Also see Xbox One GPU Memory Access: ONION, GARLIC, and More, which is one of the XDK white papers.