ID3D11DeviceContext2::UpdateTiles method (d3d11_2.h)

Updates tiles by copying from app memory to the tiled resource.

Syntax

void UpdateTiles(
  [in] ID3D11Resource                        *pDestTiledResource,
  [in] const D3D11_TILED_RESOURCE_COORDINATE *pDestTileRegionStartCoordinate,
  [in] const D3D11_TILE_REGION_SIZE          *pDestTileRegionSize,
  [in] const void                            *pSourceTileData,
  [in] UINT                                  Flags
);

Parameters

[in] pDestTiledResource

Type: ID3D11Resource*

A pointer to a tiled resource to update.

[in] pDestTileRegionStartCoordinate

Type: const D3D11_TILED_RESOURCE_COORDINATE*

A pointer to a D3D11_TILED_RESOURCE_COORDINATE structure that describes the starting coordinates of the tiled resource.

[in] pDestTileRegionSize

Type: const D3D11_TILE_REGION_SIZE*

A pointer to a D3D11_TILE_REGION_SIZE structure that describes the size of the tiled region.

[in] pSourceTileData

Type: const void*

A pointer to memory that contains the source tile data that UpdateTiles uses to update the tiled resource.

[in] Flags

Type: UINT

A combination of D3D11_TILE_COPY_FLAG-typed values that are combined by using a bitwise OR operation. The only valid value is D3D11_TILE_COPY_NO_OVERWRITE. The other values aren't meaningful here, though by definition the D3D11_TILE_COPY_LINEAR_BUFFER_TO_SWIZZLED_TILED_RESOURCE value is basically what UpdateTiles does, but sources from app memory.

Return value

None

Remarks

UpdateTiles drops write operations to unmapped areas (except on Tier_1 tiled resources, where writing to unmapped areas is invalid).

If a copy operation involves writing to the same memory location multiple times because multiple locations in the destination resource are mapped to the same tile memory, the resulting write operations to multi-mapped tiles are non-deterministic and non-repeatable; that is, accesses to the tile memory happen in whatever order the hardware happens to execute the copy operation.

The tiles involved in the copy operation can't include tiles that contain packed mipmaps or results of the copy operation are undefined. To transfer data to and from mipmaps that the hardware packs into one tile, you must use the standard (that is, non-tile specific) copy and update APIs (like ID3D11DeviceContext1::CopySubresourceRegion1 and ID3D11DeviceContext1::UpdateSubresource1) or ID3D11DeviceContext::GenerateMips for the whole mipmap chain.

The memory layout of the data on the source side of the copy operation is linear in memory within 64 KB tiles, which the hardware and driver swizzle and deswizzle per tile as appropriate when they transfer to and from a tiled resource. For multisample antialiasing (MSAA) surfaces, the hardware and driver traverse each pixel's samples in sample-index order before they move to the next pixel. For tiles that are partially filled on the right side (for a surface that has a width not a multiple of tile width in pixels), the pitch and stride to move down a row is the full size in bytes of the number pixels that would fit across the tile if the tile was full. So, there can be a gap between each row of pixels in memory. Mipmaps that are smaller than a tile are not packed together in the linear layout, which might seem to be a waste of memory space, but as mentioned you can't use ID3D11DeviceContext2::CopyTiles or UpdateTiles to copy to mipmaps that the hardware packs together. You can just use generic copy and update APIs (like ID3D11DeviceContext1::CopySubresourceRegion1 and ID3D11DeviceContext1::UpdateSubresource1) to copy small mipmaps individually. Although in the case of a generic copy API (like ID3D11DeviceContext1::CopySubresourceRegion1), the linear memory must be the same dimension as the tiled resource; ID3D11DeviceContext1::CopySubresourceRegion1 can't copy from a buffer resource to a Texture2D for instance.

For more info about tiled resources, see Tiled resources.

Requirements

See also

ID3D11DeviceContext2