top | item 38216387 (no title) reroute22 | 2 years ago Wow, that sounds like a very impressive level of separation of concerns. May I kindly ask for some links for further reading? If you have any handy. discuss order hn newest monocasa|2 years ago It's a pretty standard driver model internal abstraction layer.In kernel space you as the hardware manufacturer implement a display miniport driver, and heavily lean on dxgkrnl.syshttps://learn.microsoft.com/en-us/windows-hardware/drivers/d...And implement interfaces like this one for D3D12 https://learn.microsoft.com/en-us/windows-hardware/drivers/d...There's quite a bit though and it's kind of spread across several sections on MSDN. reroute22|2 years ago Thanks! valleyer|2 years ago FWIW, this is also how Metal and OpenGL work on macOS. It's hard work, for sure, but it's also a pretty common pattern.
monocasa|2 years ago It's a pretty standard driver model internal abstraction layer.In kernel space you as the hardware manufacturer implement a display miniport driver, and heavily lean on dxgkrnl.syshttps://learn.microsoft.com/en-us/windows-hardware/drivers/d...And implement interfaces like this one for D3D12 https://learn.microsoft.com/en-us/windows-hardware/drivers/d...There's quite a bit though and it's kind of spread across several sections on MSDN. reroute22|2 years ago Thanks!
valleyer|2 years ago FWIW, this is also how Metal and OpenGL work on macOS. It's hard work, for sure, but it's also a pretty common pattern.
monocasa|2 years ago
In kernel space you as the hardware manufacturer implement a display miniport driver, and heavily lean on dxgkrnl.sys
https://learn.microsoft.com/en-us/windows-hardware/drivers/d...
And implement interfaces like this one for D3D12 https://learn.microsoft.com/en-us/windows-hardware/drivers/d...
There's quite a bit though and it's kind of spread across several sections on MSDN.
reroute22|2 years ago
valleyer|2 years ago