3 ms·

I find software 3D rendering really interesting, as somebody who works on indie games. GPU-accelerated rendering is obviously much faster and you can get much b

I find software 3D rendering really interesting, as somebody who works on indie games. GPU-accelerated rendering is obviously much faster and you can get much better results; but it does have drawbacks! With GPU rendering, I spend the majority of my time testing and debugging on various platforms. 3D APIs are very complex, hardware capabilities vary a lot and driver quality is very poor. So even though you can get much better results in principle, in practice you can't get it as good as you hoped (or at least I can't) while also making it robust and reliable. With software rendering, you needed a ton of effort (by really smart programmers like Barrett) to get viable results, but at least you had confidence that it would work on everybody's computer, rather than crashing randomly on drivers that don't implement a 300-page 3D spec correctly. I'm told that Vulkan should improve matters, being simpler and better-specified than OpenGL, but I'm skeptical. It still seems very complex, and it doesn't run everywhere yet so it's not a great fit for low-end indie games.

jeremiep 10y ago
"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.
oppositelock 10y ago
For some background, I've been writing 3D code since the early '90's and spent years working at SGI, games studios, all doing realtime 3D. The tech pendulum swings between solving problems in hardware vs software constantly. Right now, we're somewhere between the two endpoints with the way shaders moved a lot of ASIC behavior into software. Software vs hardware 3D rendering speed is just one aspect of the differences between both approaches. Hardware graphics pipelines all share a common design - a high throughput deep pipeline which maximizes geometry and pixel throughput. The hardware is incredibly powerful, but you're still communicating with it via a thin little unidirectional pipe relative to its performance, so by using hardware, you end up having a common architecture in rendering engines; that of a retain mode renderer which tries to upload as much static content to the card as possible, then spends whatever time is possible on animated content. That's why today's games all look positively glorious and beautifully shaded, but if you look close, they're all fundamentally a few characters moving around a large static world. The 3D hardware systems simply aren't optimized for dynamically changing all that much of the scene. Back when we did pure software rendering, we had much more flexibility in our approaches, and there was a lot more dynamic rendering - fully deformable worlds. I miss the huge variety of games which were possible back then. They are still possible today, since hardware is far more capable, but due to being off the optimized path, you can't compete on look and feel, so you lose in the market.

jeremiep 10y ago

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

oppositelock 10y ago

For some background, I've been writing 3D code since the early '90's and spent years working at SGI, games studios, all doing realtime 3D. The tech pendulum swings between solving problems in hardware vs software constantly. Right now, we're somewhere between the two endpoints with the way shaders moved a lot of ASIC behavior into software. Software vs hardware 3D rendering speed is just one aspect of the differences between both approaches. Hardware graphics pipelines all share a common design - a high throughput deep pipeline which maximizes geometry and pixel throughput. The hardware is incredibly powerful, but you're still communicating with it via a thin little unidirectional pipe relative to its performance, so by using hardware, you end up having a common architecture in rendering engines; that of a retain mode renderer which tries to upload as much static content to the card as possible, then spends whatever time is possible on animated content. That's why today's games all look positively glorious and beautifully shaded, but if you look close, they're all fundamentally a few characters moving around a large static world. The 3D hardware systems simply aren't optimized for dynamically changing all that much of the scene. Back when we did pure software rendering, we had much more flexibility in our approaches, and there was a lot more dynamic rendering - fully deformable worlds. I miss the huge variety of games which were possible back then. They are still possible today, since hardware is far more capable, but due to being off the optimized path, you can't compete on look and feel, so you lose in the market.