Quote Originally Posted by ZorbaTHut View Post
Quote Originally Posted by Exceptionthrown View Post
I'm curious if the survey you guys did a while back is what started this ball rolling?
To be honest, I'm not entirely sure. From my perspective, it got rolling because I had some time spare, was starting to understand how our game rendering worked, and had a few ideas to improve performance. It's entirely possible that the management was going to push for this due to the survey, or that my boss encouraged it due to the survey.But my side of it, at least, got started by me saying "hey I think we can make this thing faster".
Quote Originally Posted by Exceptionthrown View Post
It sounds like most of the optimizations you're working on are CPU related. Have you found during your performance testing that in general the workload assigned to the GPU is within an acceptable range and therefore the effort on that path is less important than CPU optimizations? If the GPU isn't being fully utilized through the rendering pipeline, is it possible to offload some of the work the CPU is doing onto the GPU in order to alleviate some of the performance issues you mentioned?
Well, a few answers here.First, there's a vague heuristic you can use to figure out where your effort is best spent. Look at the CPU and GPU utilization. See which is higher. Focus on that. The theory is that many of these values are really per-frame numbers, so if your CPU is at 100% utilization and GPU is at 50%, then by halving the CPU usage, you actually end up doubling framerate while simultaneously pushing GPU up to 100%.Second, CPU optimizations tend to be a lot easier. GPU optimizations are finicky and can often be chip-specific or even driver-specific, or cause weird unexpected side effects. It's also sometimes unclear what can be improved. It's easy to run a profiler over your code and say "oh hey this function should probably not be using 1% of the entire CPU budget", but profilers with that kind of detail largely don't exist for the GPU (for good reason - GPU architecture is a whole lot more complicated than that) and even if they did, there are fewer parts of a renderer and most of them can be expected to use great big blobs of time.Next, offloading stuff from the CPU to the GPU is actually really difficult. It's not just a matter of flipping a switch, at best it would be a near-complete rewrite of the feature. Most CPU code isn't even suitable for moving to the GPU.In terms of analogy, a CPU is a fighter jet, capable of moving one thing very, very quickly. A GPU is a cargo ship, capable of moving an incredible amount of stuff, in parallel, but very slowly. The sheer capacity of a cargo ship means that it's better for bulk shipping - but if you need to get from New York to Paris in just a few hours, a cargo ship isn't gonna do it.Most code is far more suitable for the "fighter jet" model - you need to finish small things fast and get a response really quickly. It's actually very uncommon for code to be suitable for the bulk-processing model that GPUs specialize in.Finally, it's somewhat ironic that despite the CPU being the bottleneck, the project I'm working on right now is actually moving things from the GPU to the CPU. But I promise there's good reason for this and I'll go into it in more detail if it pans out.
Quote Originally Posted by Exceptionthrown View Post
It would be awesome if you could describe (perhaps at a high-level) the workflow that occurs during development as I'm sure others are curious. For example, I'm guessing there are multiple passes that occur when new features/code is implemented. Are there any passes that are done specifically for optimization (as opposed to bug fixes)?
The game industry is often a lot more ad-hoc than you're thinking The big issue is that every game studio is perpetually starved for time. Every feature has to be evaluated, not based on whether it would be a fun feature or not, but based on whether it would be more fun than the other things we could be doing in the same timeframe.What often happens is someone comes up with a feature and lists a few major steps to take to fully implement it. First we do X. Then we do Y. Then we do Z. So we do X, and it turns out X on its own is really fun, and we add a small chunk of Y and then nobody can come up with a good reason to bother with the rest of Y, or a good reason to even start Z.This is what happened with the public group system - somewhere buried in my email archives is a short writeup on ways to improve it and flesh it out even more. I think we got through the first step-and-a-half, maybe, before saying "hey this is good and all this extra stuff isn't really needed". Would the extra stuff be fun? Yeah, probably. And it'd be cool to do them. But overall, the players would rather have me improving the framerate than spending a bunch more time on features which would be kind of entertaining but wouldn't really improve the game.Major work towards optimization usually falls in that category. Implement a feature, see if it's a major CPU or GPU hit. If it's not, don't worry about it. Optimization passes are usually done much later, as part of a larger-scale sweep to find hotspots, which - more often than not - end up springing up in code that was previously fine anyway, as opposed to the new code.Quick example - you may have noticed a fix that went in a few weeks back to improve the crafting dialog performance. Turns out we had a pretty big speed problem when you got hundreds of recipes. This simply wasn't possible to do back when we implemented that dialog because we didn't have that many recipes, but our designers have been busily adding hundreds of recipes since. If we'd spent more time on optimization back then, we still wouldn't have found the real problem!Most features aren't a significant CPU hit, even if implemented in a really basic and simple manner. Basic and simple is better for bug prevention anyway, so usually the feature just stops there until we have to go back to it for some reason.
Jump to post...