Hi, 
I have been busy for long time so I couldn't play around  with Dx12.
Well, I got a very simple and basic question.
I have read the API references ,did googling but didn't get much information.

It is about this API,  ID3D12DescriptorHeap::GetCPUDescriptorHandleForHeapStart().
And , ID3D12DescriptorHeap::GetGPUDescriptorHandleForHeapStart()

I'm confusing.
What Get"CPU"  and Get"GPU" means? 

1) Is it means that one is a handle for CPU and the other a handle for GPU against the same virtual address or something?

[ same address ] ---> for CPU handle    [ same address ] ---> for GPU handle

or

2) It means that there are 2 different addresses and those handles are representing respectively? 

[  system memory address ] ---> for CPU handle    [ GPU memory address ] ---> for GPU handle

Those 2 API returns 2 different values(addresses) so I guess 2 is the answer but I want to sure.

Think of it as two different virtual addresses for the same physical address. One of those addresses can be used to locate the descriptor on the CPU, so that the driver can write to it, while the other can be used to locate it on the GPU, so that it can be read.

2 hours ago, SoldierOfLight said:

Think of it as two different virtual addresses for the same physical address. One of those addresses can be used to locate the descriptor on the CPU, so that the driver can write to it, while the other can be used to locate it on the GPU, so that it can be read.

is the 'same physical address' on the GPU's memory? I  thought of CPU handle is for when the driver needs to modify content of GPU's physical memory, like descriptor heap in this case. But I still don't get an idea why then OMsetRenderTargets/CleareRenderTargetView require CPU_HANDLE, thinking the APIs tell GPU to use render targets. does driver need to access render target regarding swapchain stuff? 

For a shader-visible descriptor heap, yes the memory likely lives on the GPU, though that's an implementation detail -- it's accessed through a virtual address, so it doesn't really matter where the memory lives, the handle will still be valid. For a non-shader-visible heap, the memory does not live on the GPU.

Render target descriptors are not stored in shader-visible heaps. Instead, the information for programming the GPU to select a specific render target is embedded in the command list, meaning that the driver reads the information from the descriptor at bind time. For other descriptors, like SRVs or UAVs, the driver doesn't read the descriptor, the hardware reads it directly, which is why a GPU descriptor handle is used.

17 hours ago, SoldierOfLight said:

Think of it as two different virtual addresses for the same physical address. One of those addresses can be used to locate the descriptor on the CPU, so that the driver can write to it, while the other can be used to locate it on the GPU, so that it can be read.

Very clear and precise.
I could get it 100% due to the perfect answer.
Moreover, the virtual memory stuff

14 hours ago, SoldierOfLight said:

For a shader-visible descriptor heap, yes the memory likely lives on the GPU, though that's an implementation detail -- it's accessed through a virtual address, so it doesn't really matter where the memory lives, the handle will still be valid. For a non-shader-visible heap, the memory does not live on the GPU.

This is the other topic i have been wondering too.
Thank you very much.