Talked to a tech at a custom laptop builder today. Heard some disturbing news. If I wanted a single dGPU laptop which had ability to scan-out from the dGPU, I was limited to Asus models G750JW/G750JX/G750JH, all of which support NVIDIA GPUs only and definitely not Maxwell (they said all of the current Maxwell GPUs are Optimus only). All other single dGPU laptops they carry with NV or AMD only have scan-out from the iGPU.
From the IHV perspective this lowers cost, the dGPU does not need to burn area and power on display hardware which gets duplicated. Makes sense for the average case. Except my target is semi-portable VR, I cannot afford the latency and variability of the dGPU to iGPU back-buffer copy.
Details
If I'm reading specs right MXM (mobile PCIe) 3.0 could only get 8 GB/s max, and MXM 3.1 tops at 16 GB/s. Not sure what laptops actually get in practice. At 8 GB/s, time for a 1080p frame transfer would be around 1ms. At 120Hz that is around 1/8 of the frame time. Typically last draws into the back buffer are blending operations for the UI, and not something which one would want to do across PCIe. Blending operations on modern cards are the wrong way to do things anyway (easily export limited). Alternative would be to have the last drawing operation as a full screen triangle composite pass which would apply some amount of post processing in conjunction with adding the UI. Just 1ms on say a GTX 880M at 1080p has capacity for maybe around 60 tex/pixel, 80 bytes/pixel, and 1.4 Kflops/pixel. It might be hard in some engines to fully utilize the GPU on a PCIe store limited final post process pass taking 1ms. However what I typically do involves heavy filtering which can saturate the GPU in this case.
From my understanding, the bigger problem is that the driver "handles" it for you in the worst way possible. Currently I know of no interface which enables the application to get a texture handle to the physical CPU-side back buffer in the iGPU+dGPU situation. My understanding is that instead there is some CPU/GPU sync point which enables CPU side code to then schedule the GPU->CPU copy, which then adds a long variable latency.
From the IHV perspective this lowers cost, the dGPU does not need to burn area and power on display hardware which gets duplicated. Makes sense for the average case. Except my target is semi-portable VR, I cannot afford the latency and variability of the dGPU to iGPU back-buffer copy.
Details
If I'm reading specs right MXM (mobile PCIe) 3.0 could only get 8 GB/s max, and MXM 3.1 tops at 16 GB/s. Not sure what laptops actually get in practice. At 8 GB/s, time for a 1080p frame transfer would be around 1ms. At 120Hz that is around 1/8 of the frame time. Typically last draws into the back buffer are blending operations for the UI, and not something which one would want to do across PCIe. Blending operations on modern cards are the wrong way to do things anyway (easily export limited). Alternative would be to have the last drawing operation as a full screen triangle composite pass which would apply some amount of post processing in conjunction with adding the UI. Just 1ms on say a GTX 880M at 1080p has capacity for maybe around 60 tex/pixel, 80 bytes/pixel, and 1.4 Kflops/pixel. It might be hard in some engines to fully utilize the GPU on a PCIe store limited final post process pass taking 1ms. However what I typically do involves heavy filtering which can saturate the GPU in this case.
From my understanding, the bigger problem is that the driver "handles" it for you in the worst way possible. Currently I know of no interface which enables the application to get a texture handle to the physical CPU-side back buffer in the iGPU+dGPU situation. My understanding is that instead there is some CPU/GPU sync point which enables CPU side code to then schedule the GPU->CPU copy, which then adds a long variable latency.