3 ms·

"Much Faster" is a bit of an understatement. Sure, "vastly faster" then, if you like. :) Vulkan IS simpler than OpenGL I hope so! I haven't yet used it serio

"Much Faster" is a bit of an understatement. Sure, "vastly faster" then, if you like. :) Vulkan IS simpler than OpenGL I hope so! I haven't yet used it seriously. I don't care so much about simplicity per se, I just really really hope it's more reliable. I'm skeptical because the design rationale seems to be "make it simple so that implementations can be fast" rather than "make it simple so that implementations are more likely to be correct". Hopefully those will go hand in hand though. And even in software rendering you still get different results on different hardware That's true -- I considered editing my post to mention that but felt it wasn't relevant enough. It's true that any high-performance software engine will have tuning for cache efficiency, inline assembler (or at least intrinsics) for SIMD and the like. But I think the situation for software is still easier than for accelerated 3D. 98% of software will Just Work anywhere; the remaining 2% is stuff you've explicitly hand-optimized, and might be fiddly to port, but you can at least write tests for those parts. In accelerated 3D, almost anything can and will fail on some platform, and automated testing is much harder. You're right that floating-point gets fiddly (but not nearly as much as floating-point on GPUs, which vary enormously in precision!) And multithreaded software is definitely a different beast. That's very hard, and different CPUs have different memory models. But even there, you aren't typically hampered by bad drivers. You can't replace having to learn the hardware and the APIs to access it in order to build a game engine. I think I only partly agree. My beef with 3D hardware acceleration is that while the hardware is ridiculously fast, it's also very flaky, with tremendous differences between platforms even when they claim to implement the same API. Using a framework like Unreal or Unity helps a lot, but still doesn't entirely fix the problem. Some of Unity's basic demos don't work correctly on all versions of Android (they use textures with alpha, but Android defaults to ETC1 textures which don't support alpha). Overall, I'm not saying there's a solution to any of this, just lamenting the fact that 3D hardware acceleration is so painful! And I still think it's painful in a qualitatively different way from plain unaccelerated software. Current APIs are simply not dependable. I do hope Vulkan will be a major improvement.

jeremiep 10y ago
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.

jeremiep 10y ago

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.