5 ms·

"Much Faster" is a bit of an understatement. The last software rendered title I can think of is the first Unreal Tournament. No CPU can handle the load of a mod

"Much Faster" is a bit of an understatement. The last software rendered title I can think of is the first Unreal Tournament. No CPU can handle the load of a modern game's graphics, not even close. Even badly integrated OpenGL is still orders of magnitude faster than the most optimized software rendering. And you're getting a lot more in terms of image quality on the GPU: texture filtering, anti aliasing, "free" conversions to gamma/linear space and more. Vulkan IS simpler than OpenGL, theres no arguing about that. But simpler does not mean easier. There's just much less stuff to worry about as engine developers to hit the fast path. On the other hand, you're managing a lot more memory by yourself. And even in software rendering you still get different results on different hardware. And even different results in debug vs release. Floating point arithmetic is fun like that. CPUs varies in power just like GPUs do; cache sizes vary greatly, number of cores, base clock speed, amount of available memory, memory speed, etc. And we're not even touching SIMD yet. You can't replace having to learn the hardware and the APIs to access it in order to build a game engine. That was also true of software renderers; they're closely tied to the properties of the CPU they target. That's why you get access to Unreal4 or Unity3D; very, very few people can actually make stable and portable game engines. Its just a hard problem space to begin with. Making it easier only means losing lots of flexibility and performance.

qwertyuiop924 10y ago
>The last software rendered title I can think of is the first Unreal Tournament. Deus Ex had software rendering as well. But that was on an engine derived from the UT one.
iainmerrick 10y ago
"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.
dfox 10y ago
One thing to consider there is that today most 2D inide games are in reality rendered by 3D hardware pipeline (because of some middleware that just maps anything to Direct3D/OpenGL ES, today this includes even SDL) and that is the use case where you (a) don't need hardware acceleration for rendering at all and (b) trigger obscure driver/hardware bugs that nobody cares about because they are irrelevant for truly 3D engines.
- jeremiep 10y ago
  So long as your 2D game doesn't have lighting or require shaders. You'd limit yourself to vector rasterizing and blitting bitmaps. There are loads of 2D games out there pushing the GPU far enough that they would never run in software rendering.

qwertyuiop924 10y ago

>The last software rendered title I can think of is the first Unreal Tournament. Deus Ex had software rendering as well. But that was on an engine derived from the UT one.

iainmerrick 10y ago

"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.

dfox 10y ago

One thing to consider there is that today most 2D inide games are in reality rendered by 3D hardware pipeline (because of some middleware that just maps anything to Direct3D/OpenGL ES, today this includes even SDL) and that is the use case where you (a) don't need hardware acceleration for rendering at all and (b) trigger obscure driver/hardware bugs that nobody cares about because they are irrelevant for truly 3D engines.

jeremiep 10y ago
So long as your 2D game doesn't have lighting or require shaders. You'd limit yourself to vector rasterizing and blitting bitmaps. There are loads of 2D games out there pushing the GPU far enough that they would never run in software rendering.