1. Is there any way to use a chunk of an allocation (sysmem heap, that will be used for staging/upload) as the the backing surface of a GDI memory DC? In previous D3D iterations this was formally supported by way of IDXGISurface→GetDC(). Sharing of heaps seemed promising as presumably it would be implemented via a section however the docs state any allocation visible to the CPU is unable to be shared (unless I missed something here?)
   
   
2. While experimenting with “waitable” swapchains I'm observing some unusual behaviour where-in submitting a frame via Present() is taking anywhere from 150μs to 2ms. Interestingly however, simulating [CPU] work rather than just clearing+flipping results in far less jitter and times on the low-end – maybe the system is just releasing the thread waiting on the swapchain semaphore effectively earlier than would be possible to re-issue a new frame, either just by design or as an optimization under the assumption the CPU-side frame generation takes a non-negligible amount of time?
   

1. No, D3D12 doesn't have GDI interop.
2. The Windows CPU scheduler doesn't have a guarantee of being able to wake up threads at such a small granularity. What you're talking about here is submitting a frame, having the compositor wake up and consume that frame, and then allowing the app to wake up again, which could take up to 2ms just for the CPU scheduler I believe.

Also, these days we generally take questions on our Discord server: https://discord.com/invite/directx​

That's unfortunate regarding GDI.

SoldierOfLight said:

1. The Windows CPU scheduler doesn't have a guarantee of being able to wake up threads at such a small granularity. What you're talking about here is submitting a frame, having the compositor wake up and consume that frame, and then allowing the app to wake up again, which could take up to 2ms just for the CPU scheduler I believe.​

I understand Windows is not a RTOS however the sort of latencies we're talking about are not explained by scheduling delays –a blocking local RPC (ALPC) has about a ~60μs RTT-- and moreover as mentioned, this jittery/spikey behavior is not exhibited when a brief delay is introduced between the waiter being released and issuing the Present(). ie.:

for(;;)
{
	WaitForSingleObject(hWaitableSwapChain);
	Present(1, NULL); // averages 500μs, frequent peaks up to 2ms.
}

for(;;)
{
	WaitForSingleObject(hWaitableSwapChain);
	QPCSpin(5ms);
	Present(1, NULL); // averages 150μs, very little variation.
}

Also importantly I forgot to mention: specifying 0 for the sync. interval in submission results in near-constant Present() time of ~80μs which further suggests it's some internal synchronization issue. Note that I'm testing this while engaging Independent-Flip (verified with PresentMon)

Thanks for your help and the Discord suggestion; I posted here mainly for the benefit of others looking for answers.

EDIT: To be clear, I'm interested in determining whether this behavior is a consequence of my misunderstanding/implementation of waitable swapchains/D3D rather than pedantry over clock cycles.