3 ms·
Oof. I'd love to know why. If I had to guess it's related to how DirectX12/Vulkan/Metal/Mantle are all about the basic idea that if you have a full MMU on the
by monocasa 5y ago
Oof. I'd love to know why.
If I had to guess it's related to how DirectX12/Vulkan/Metal/Mantle are all about the basic idea that if you have a full MMU on the GPU, you can expose a more direct, console like API. The idea being that at worst you can only crash your own process's GPU context and that was always allowed. Maybe Intel found a hole in their MMU's implementation that lets you break out from the GPU side? I feel like it would have to be some hardware issue that fundamentally break's DX12's value add if patched to decide to just wholesale remove the feature.
- kevingadd 5y agoAs a game dev "you can expose a more direct, console like API. The idea being that at worst you can only crash your own process's GPU context and that was always allowed." is extremely funny to me. Any time I test Vulkan code on my machine I make sure to save all my work first since if the code has any bugs it has a decent chance of trashing kernel data structures and causing a BSOD.
- monocasa 5y agoThe primitives being in place (virtual addresses in GPU data structures like the command lists, letting user space manage GPU memory) says nothing about there being bugs in the drivers or not.
- Jasper_ 5y agoIt's worth noting that Haswell only ever supported Tier1 resource binding on DX12, so none of the new bindless stuff would even be to blame. I suspect this won't affect any projects too harshly, because anything DX12 exclusive probably requires at least Tier2 resource binding support. But I'm guessing something in the resource binding system is to blame...