4 ms·

I'm not saying GPU vendors are perfect either - most of them are terrible. I have nothing but curses when it comes to Adrenos GPUs for one. Most of the problems

I'm not saying GPU vendors are perfect either - most of them are terrible. I have nothing but curses when it comes to Adrenos GPUs for one. Most of the problems you list come from the vendors, not the APIs in between - it would be a hundred times worse without GL or DX. Its also worth noting that the GL/DX you see is vastly different than the raw API exposed by the hardware. You don't want to generate command buffers for 200 models of GPU. You don't want to assemble shaders in 200 variants of similar instruction sets. I'm no hardware guy but I'm sure standardizing the GPU's instruction sets like X86 is would come with its own bag of drawbacks. There's also a lot of historic baggage and hiccups to account for.

iainmerrick 10y ago
I think we're mostly agreeing, and where we're not I bow to what sounds like greater experience. :) I definitely agree that a) GL and DX help, and b) both are still really painful to work with. Do you think Vulcan is going to be a big improvement? I'm specifically interested in how confident we can be that our code will run properly more or less everywhere, without lots of testing and debugging on lots of different devices.
- jeremiep 10y ago
  Vulkan won't help with correctness. A bad driver or a bad GPU will keep on doing the wrong thing no matter what API you use to fill its command buffer. I never believed in the "write once, run everywhere" thing to begin with. Its not true with C#/Java, definitely not true with web dev, and most certainly not true with GPUs. It looks good in theory but rarely ever works in practice. What Vulkan/DX12 helps with is exposing a lot more of the GPU's low-level details to engine programmers. This has the negative impact that all the complexity is now in the hands of engine devs. But the upside is that now finally the engine and the driver can stop guessing about what each other is doing. That was a good thing decades ago when APIs were much, much simpler than they are today. Nowadays its near impossible to hit the fast path of GL4/DX11 without serious investment because of everything the driver does to "protect" you and make your life "easier"; it grew into a complexity monster. So its actually harder to use Vulkan than it is to use OpenGL. But once you learn it it becomes simpler to work with.

iainmerrick 10y ago

I think we're mostly agreeing, and where we're not I bow to what sounds like greater experience. :) I definitely agree that a) GL and DX help, and b) both are still really painful to work with. Do you think Vulcan is going to be a big improvement? I'm specifically interested in how confident we can be that our code will run properly more or less everywhere, without lots of testing and debugging on lots of different devices.

jeremiep 10y ago
Vulkan won't help with correctness. A bad driver or a bad GPU will keep on doing the wrong thing no matter what API you use to fill its command buffer. I never believed in the "write once, run everywhere" thing to begin with. Its not true with C#/Java, definitely not true with web dev, and most certainly not true with GPUs. It looks good in theory but rarely ever works in practice. What Vulkan/DX12 helps with is exposing a lot more of the GPU's low-level details to engine programmers. This has the negative impact that all the complexity is now in the hands of engine devs. But the upside is that now finally the engine and the driver can stop guessing about what each other is doing. That was a good thing decades ago when APIs were much, much simpler than they are today. Nowadays its near impossible to hit the fast path of GL4/DX11 without serious investment because of everything the driver does to "protect" you and make your life "easier"; it grew into a complexity monster. So its actually harder to use Vulkan than it is to use OpenGL. But once you learn it it becomes simpler to work with.