In the upcoming major update to Windows 10 OS, the DirectX12, and more specifically, the Direct3D (D3D12), will be getting not one but new flags that will alter the way memory resources are allocated. It appears Microsoft is rightly concerned about the way memory and processing power are requested by and allocated to applications, which can often create a bottleneck. Incidentally, these new flags will not directly impact the memory, but will rather affect the way it is allocated and managed.
Microsoft has been actively developing the latest iteration of the DirectX platform, which has long been a leading standard for desktop gaming. The latest version of Microsoft DirectX 12 has been getting several new features lately. Recently we covered the most prominent and important new features to DirectX 12 which would significantly benefit developers and end-users. This week, Microsoft indicated the next major update to Windows 10 should include two new flags for the DirectX12 Direct3D. Interestingly, developers who wish to explore the same today, need to simply download and install the latest Windows 10 Insider Preview build and SDK Preview Build for Windows 10 (20H1) from the Windows Insider Program.
Windows 10 DirectX 12 Direct3D To Get Two New Flags For Dynamic Memory Allocation Between CPU and GPU:
In the upcoming update to Windows 10, D3D12 will be adding two new flags to the D3D12_HEAP_FLAG enumeration. Incidentally, these new flags are “impermanent” properties. Simply put, this means that the new flags won’t directly affect the resulting memory itself. Instead, the new flags will affect the way the memory is allocated. Moreover, these flags aren’t reflected from ID3D12Heap::GetDesc or ID3D12Resource::GetHeapProperties.
In its current iteration, whenever a developer requests D3D to allocate a heap or committed resource, the last thing that happens before he gets back the object is the memory gets made resident. This is remarkably similar to ID3D12Device::MakeResident being performed. Needless to add, such a process presents two issues right away:
- The design blocks a CPU Thread until the memory is fully ready to use. This is not an ideal or desired situation
- The process will also allow developers to overcommit memory, beyond what the current process budget indicates he should be using.
The newly added ID3D12Device3::EnqueueMakeResident allows apps to make different choices. The apps could wait for residency using the GPU rather than the CPU or request the residency operation to fail rather than going over-budget. Allocation of memory in a non-resident state results in imparting both the benefits to the first use of resources.
This flag attempts to address zeroed contents that committed resources and heaps newly created by D3D received. Microsoft attempted to optimize this process by enabling more re-use memory that had never left the confines of a given process without zeroing. However, this did not work well and forced Microsoft engineers to go back to returning only zeroed memory. Needless to mention, this way was quite tedious as the memory manager needs to explicitly write zeroes into the memory before it returns it to the developers for reuse.
As a way to optimize the process, developers are being granted the ability to opt-out of the tedious process by simply specifying the new flag during heap/resource allocation. Essentially, the dynamic reallocation could minimize the mandatory all-time zeroing process, and allocate some freed memory that the developer’s processes were using without forcing it through the re-zero process.
Microsoft has already added these new flags and they do not require new drivers. Moreover, there is no dedicated CheckFeatureSupport option for these. Essentially, these new flags are available anytime that ID3D12Device8 is exposed, or a check for D3D12_FEATURE_D3D12_OPTIONS7 succeeds. All the new flags demand is that the developers should be running processes on a version of D3D12 which understands them.