> ## Documentation Index
> Fetch the complete documentation index at: https://devdocs.xbox.com/llms.txt
> Use this file to discover all available pages before exploring further.

# D3D12_FEATURE_DATA_ARCHITECTURE

> Provides detail about the adapter architecture, so that your application can better optimize for certain adapter properties.

Provides detail about the adapter architecture, so that your application can better optimize for certain adapter properties.
<div class="alert">**Note**  This structure has been superseded by the [D3D12\_FEATURE\_DATA\_ARCHITECTURE1](/reference/graphics/d3d12/structs/d3d12_feature_data_architecture1_public) structure. If your application targets Windows 10, version 1703 (Creators' Update) or higher, then use **D3D12\_FEATURE\_DATA\_ARCHITECTURE1** (and [D3D12\_FEATURE\_ARCHITECTURE1](/reference/graphics/d3d12/enums/d3d12_feature_public)) instead.</div><div> </div>

## Syntax

```cpp theme={null}
typedef struct D3D12_FEATURE_DATA_ARCHITECTURE
{
    UINT NodeIndex;
    BOOL TileBasedRenderer;
    BOOL UMA;
    BOOL CacheCoherentUMA;
} D3D12_FEATURE_DATA_ARCHITECTURE
```

### Members

*NodeIndex*\
Type: UINT

In multi-adapter operation, this indicates which physical adapter of the device is relevant.
See [Multi-adapter systems](https://learn.microsoft.com/en-us/windows/win32/direct3d12/multi-engine).
**NodeIndex** is filled out by the application before calling [CheckFeatureSupport](/reference/graphics/d3d12/interfaces/id3d12device/methods/id3d12device_checkfeaturesupport_public), as the application can retrieve details about the architecture of each adapter.

*TileBasedRenderer*\
Type: BOOL

Specifies whether the hardware and driver support a tile-based renderer.
The runtime sets this member to **TRUE** if the hardware and driver support a tile-based renderer.

*UMA*\
Type: BOOL

Specifies whether the hardware and driver support UMA.
The runtime sets this member to **TRUE** if the hardware and driver support UMA.

*CacheCoherentUMA*\
Type: BOOL

Specifies whether the hardware and driver support cache-coherent UMA.
The runtime sets this member to **TRUE** if the hardware and driver support cache-coherent UMA.

## Remarks

<h3><a id="How_to_use_UMA_and_CacheCoherentUMA" /><a id="how_to_use_uma_and_cachecoherentuma" /><a id="HOW_TO_USE_UMA_AND_CACHECOHERENTUMA" />How to use UMA and CacheCoherentUMA</h3>
D3D12 apps should be concerned about managing memory residency and providing the optimal heap properties.
D3D12 apps can stay simplified and run reasonably well across many GPU architectures by only managing the residency for resources in [D3D12\_HEAP\_TYPE](/reference/graphics/d3d12/enums/d3d12_heap_type_public)\_DEFAULT heaps.
Those apps only need to call [IDXGIAdapter3::QueryVideoMemoryInfo](https://learn.microsoft.com/en-us/windows/win32/api/dxgi1_4/nf-dxgi1_4-idxgiadapter3-queryvideomemoryinfo) for DXGI\_MEMORY\_SEGMENT\_GROUP\_LOCAL,
and they must be tolerant that D3D12\_HEAP\_TYPE\_UPLOAD and D3D12\_HEAP\_TYPE\_READBACK come from that same memory segment group.

However, such a simple design is too constraining for applications that push the limits.
So, D3D12\_FEATURE\_DATA\_ARCHITECTURE helps applications better optimize for the underlying adapter properties.

Some applications may want to better optimize for discrete adapters, and take on the additional complexity of managing both system memory and video memory budgets.
If the size of upload heaps rivals the size of default textures, a near doubling of memory utilization is available.
When supporting such optimizations, an application can either detect two residency budgets or recognize **UMA** is **false**.

Some applications may want to better optimize for integrated/ UMA adapters, especially those that are interested in extending battery life on mobile device.
Simple D3D12 applications are forced into copying data between heaps with different attributions, when it isn't always necessary on UMA.
However, the UMA property, by itself, encompasses a reasonably vague grey area of GPU designs.
Do not assume UMA means all GPU-accessible memory can be freely made CPU-accessible, because it doesn't.
There's a property that more closely aligns to that type of thinking: **CacheCoherentUMA**.

When **CacheCoherentUMA** is **false**, a single residency budget is available but the UMA design commonly benefits from the three heap attributions.
Opportunities do exist to remove resource copying through wise usage of upload and readback resources and heaps, that provide CPU-access to the memory.
Such opportunities are not clear-cut, though.
So, applications should be cautious; and experimentation across a variety of "UMA" systems is advisable, as resorting to enabling or precluding certain device IDs may be warranted.
An understanding of the GPU memory architecture and how heap types translate to cache properties is recommended.
The feasibility of success is likely dependent on how often each processor either reads or writes the data, the size and locality of data accesses, etc.
For advanced developers: when **UMA** is true and **CacheCoherentUMA** is **false**, the most unique characteristic for these adapters is that upload heaps are still write-combined.
However, some UMA adapters benefit from both the no-CPU-access and write-combine properties of default and upload heaps.
See [GetCustomHeapProperties](/reference/graphics/d3d12/interfaces/id3d12device/methods/id3d12device_getcustomheapproperties_public) for more details.

When **CacheCoherentUMA** is true, applications can more strongly entertain abandoning the attribution of heaps and using the custom heap equivalent of upload heaps everywhere.
Zero-copy UMA optimizations are more generally encouraged as more scenarios will just benefit from shared usage.
The memory model is very conducive to more scenarios and wider adoption.
Some corner cases may still exist where benefits are not easily obtained, but they should be much rarer and less detrimental than other options.
For advanced developers: **CacheCoherentUMA** means that a significant amount of the caches in the memory hierarchy are also unified or integrated between the CPU and GPU.
The most unique observable characteristic is that upload heaps are actually write-back on **CacheCoherentUMA**.
For these architecture, the usage of write-combine on upload heaps is commonly a detriment.

The low-level details should be ignored by a vast majority of single-adapter applications.
As usual, single-adapter applications can simplify the landscape and ensure that the CPU writes to upload heaps use patterns that are write-combine-friendly.
The lower-level details help reinforce the concepts for multi-adapter applications.
Multi-adapter applications likely need to understand adapter architecture properties well enough to choose the optimal custom heap properties to efficiently move data between adapters.

## Requirements

**Header:** d3d12\_xs.h or d3d12\_x.h\
**Library:** d3d12\_xs.lib or d3d12\_x.lib\
**Supported Platforms**: XBOX Series consoles and XBOX One family

## See Also

[Core Structures](https://learn.microsoft.com/en-us/windows/win32/direct3d12/direct3d-12-structures)

[D3D12\_FEATURE](/reference/graphics/d3d12/enums/d3d12_feature_public)


## Related topics

- [D3D12_FEATURE_DATA_ARCHITECTURE1](/reference/graphics/d3d12/structs/d3d12_feature_data_architecture1_public.md)
- [D3D12_HEAP_TYPE](/reference/graphics/d3d12/enums/d3d12_heap_type_public.md)
- [D3D12_FEATURE](/reference/graphics/d3d12/enums/d3d12_feature_public.md)
- [D3D12_FEATURE_DATA_D3D12_OPTIONS](/reference/graphics/d3d12/structs/d3d12_feature_data_d3d12_options_public.md)
- [D3D12_FEATURE_DATA_D3D12_OPTIONS5](/reference/graphics/d3d12/structs/d3d12_feature_data_d3d12_options5_public.md)