Phew, I’m 21 presentations into 2019 and I’ve only just finished all the ones that start with “A”
2019 is gonna be a long year
Remote
GDC Presentation Reviews
@GDCPresoReviews@mastodon.gamedev.place
mastodon 4.7.3Reviewing GDC programming presentations based on my own arbitrary criteria, in roughly chronological order.
Not affiliated with GDC.
A score of > 5 roughly means I’d recommend watching/listening. < 5 roughly means I wouldn’t.
I review the presentation in the context of today, not in the context of which they were presented.
Q&A portions of presentations are not considered.
Raw scores: https://docs.google.com/spreadsheets/d/1fuxpeyMLwi83xeWtJfKR4O2ot_LMA--EGmINQOUXqKg/edit?usp=sharing
404 Followers
114 Following
34 Posts
Joined June 05, 2024
GDC 2019: "Autonomous Driving Simulation with Unity (Presented by Baidu USA)" by Jaewon Jung, Turner Sinopoli of Baidu USA https://gdcvault.com/play/1026207/Autonomous-Driving-Simulation-with-Unity
This wasn't good, for one major reason which I'll explain shortly.
This presentation was about Apollo https://www.apollo.auto/en/ which they described as, literally, "a ... platform for its partners to develop their own ... systems." If this isn't meaningless, I don't know what is.
1/5
GDC 2019: "Advanced Graphics Techniques Tutorial: Wakes, Explosions and Lighting: Interactive Water Simulation in 'Atlas'" by Mark Mihelich of Studio Wildcard (despite them introducing themselves as being from Grapeshot Games), Tim Tcheblokov of NVIDIA https://gdcvault.com/play/1025819/Advanced-Graphics-Techniques-Tutorial-Wakes
This was a very deep (pun intended) presentation, specifically about ocean rendering. They spent roughly half the time talking about simulation and half talking about rendering.
1/6
GDC 2019: "Advanced Graphics Techniques Tutorial: High Zombie Throughput in Modern Graphics" by Anton Krupkin, Denis Sladkov of Saber Interactive https://gdcvault.com/play/1025817/Advanced-Graphics-Techniques-Tutorial-High
I actually liked this a lot. The first half of the presentation was about their overall frame rendering breakdown, and the second half was about how they made the zombies from a tech art perspective.
Their frame rendering was actually a fairly classic Forward+ approach.
1/6
Replying to
Review: 10/10 I found this incredibly refreshing, because it wasn't just about tech for tech's sake. This person is trying to run a business, and they were extremely clear-eyed about what the benefits and drawbacks are. And they are absolutely an expert, having shipped two of the first AAA DX12 PC ports.
This was great. Every D3D programmer should watch this one.
Replying to
Another significant point they made was that drivers will *never* stop messing with your game, if your game is high-profile. The GPU vendors are financially incentivized to do it. The fact that these new APIs are lower-level means the drivers will do *even crazier* shit to you. They said the complexity of DX12 drivers is *not* lower than the complexity of DX11 drivers. DX12 does *not* move the driver into the app.
Which absolutely rings true to me.
8/10
Replying to
So, in the end, they asked a rhetorical question: Is DX12 worth it? And they didn't answer that question. It's certainly expensive from a "paying your engineers to write to it" point of view. And they found the public reception not very positive. But they also found significant perf uplifts on many systems.
Their conclusion was basically "Be realistic. It may or may not be right for you. And don't ship both DX11 and DX12 codepaths in the same game - your players will hate you for it"
9/10
Replying to
The main takeaways are mostly:
- Linked lists defeat the out of order capabilities of the processor, and there's basically nothing you can do about it
- The hardware is already optimized for iterating through arrays, so there's not really anything you can do to speed that up
Review: 10/10 I learned a lot!!! The specific numbers aren't really relevant nowadays, but the approach he used to compare the throughput of different units, and how to measure, were really illustrative.
Replying to
They didn't pull any punches! They weren't trying to sell me anything.
- They started off saying they just flat-out don't like PSOs. The inputs to PSO creation come from various places, with various lifetimes, and you often don't know what you need to create them until it's too late. Their solution was "have QA play the game and cache all the shaders and ship the cache on disk" but I don't think that's a real solution because the stuff on disk is hardware- and driver-dependent.
3/10
Replying to
They’re generating more planets than they could possibly test, so how do they know if they’re doing a good job at generating them?
There were artists working on the game; what artistic control were they given? Did they just paint textures in photoshop all day, or did they get into the guts of the stochastic algorithms?
Review: 6/10 I liked how they broke down the world generation into tractable passes, but I was still left wanting at the end for a discussion about creative control.
Replying to
This is interesting to me, because if I was given this problem, the way I would have done it would be to query the hardware counters at every function's start and end, by using the linker to wrap every function (presented here: https://gdcvault.com/play/1015727/Runtime-CPU-Performance-Spike-Detection) So I was interested to hear that Insomniac took a completely different approach.
Review: 7/10 They said it took them 2 weeks of work, which seems like a good cost/benefit ratio. They also gave a couple examples of using it to improve real perf.
Replying to
This presentation was about their experiences, both from a technical point of view, and from a company strategic point of view, which I actually found super insightful.
They started off with performance, showing DX12 to be a significant perf win for both games, on a variety of systems, on both AMD and Nvidia.
And the speaker said "This seems like a great story. But I would say it wasn't really a great story." And then proceeded to discuss technical aspects of DX12.
2/10
Replying to
The later passes are things like adding props or digging out caves.
For polygonization, they use dual contouring, and for texturing they mostly use (what sounded like) triplanar projection.
The main thing that I think was lacking from this presentation was a discussion of how they knew how well they were doing. Like, it’s easy to generate random stuff, but it’s hard to know if you’ve generated *good* random stuff.
3/4
Replying to
At the end of the handler, you set the Trap Flag again, so the next instruction gets another trap. So your handler ends up getting called every time an instruction gets executed.
In the handler, you can parse the instruction, and look at the register state to determine which memory accesses that instruction is performing.
Now that you're seeing all the memory operations, you can model the behavior of a cache, to see whether you expect that operation to hit or miss.
2/4
Replying to
Yep :)
IMO one of the great things about this presentation is I see echoes of it nowadays:
- Making PSOs more flexible with Vulkan's Graphics Pipline Libraries (and IIRC D3D announced something similar this year)
- Players saying ray tracing isn't worth it
Replying to
- Their feedback about barriers was that their performance characteristics on different GPUs was wildly different. It was difficult to make the barriers correct, but it was really difficult to find a sequence of barriers that was semi-optimal on all devices. They went so far as to say essentially the only way to do this well would be to test on every GPU, and then flat out said that doing so would be completely impractical for their company.
4/10
Replying to
Regarding MakeResident(), they made the point that they don't want the model of "make all the resources you need resident before using them" but instead want something like "let me use the resource across the PCI bus, while making it resident in the background"
- Async compute isn't as much of a win on PC as it is on consoles, because it requires fences for synchronization, but you can't interact with a fence from within a command list in D3D12. It requires splitting your command lists.
6/10
Replying to
So all those extra calls to ExecuteCommandLists() cost significant perf.
- Explicit multi-GPU works great
But the main point of his presentation seemed to be that everyone in the industry was telling gamers for years that their performance would get 30% higher or whatever, but for enthusiasts with fast CPUs, this didn't actually happen because they weren't CPU-bound. Both DX12 games Nixxes ported had DX11 paths too, and gamers were vocally disappointed about the lack of perf increases.
7/10
Replying to
@dotstdy@mastodon.social
Ah, okay. I assumed they were talking about the various "serialize compiled PSO to binary form" APIs, but you're right, they could handle it with a "PSO burn" on startup.
I actually played both of these games on PC back in the day, and I don't remember whether they have a "PSO burn" on startup or not.
Replying to
Each cycle can only issue a single one of these cache transactions. This is why cached SIMD loads are faster than cached scalar loads: the bottleneck isn't actually the throughput of the cache, but is instead the setup time of the cache transactions. You get 4x more data out of the cache per cycle than you would if you issued scalar loads. Wild!!!
The rest of the presentation was working through examples of some common algorithms on some common data structures.
5/6
Replying to
They don’t model the interior of the planets; instead they just have a low frequency heightmap on the surface of the sphere, and there’s a sort of skin of voxels on it.
Each voxel is roughly 1m^3, and only holds a few things:
- Density
- Two material IDs
- Blending weights of the two materials
They generate the voxels in chunks of 36^3 voxels.
They generate everything in a sequence of passes; each pass writes out a data structure that the next pass reads. It’s a pipeline.
2/4
Replying to
This is neat because you can model any cache behavior - not just the cache of the machine you're running on - so they modeled the Jaguar's cache.
And they captured the instruction pointer and the stack to attribute the accesses back to source code.
In the end, they ended up with a UI like this, which colored lines of code according to how many cache misses they caused. They also had a tree view, too.
3/4
Replying to
IMO this is a clear win of Vulkan’s fence-based barrier model over D3D12’s (traditional, non-enhanced) state-based barrier model
Replying to
Another interesting thing they said about barriers I forgot to mention: if you’re recording command lists in parallel, but executing them serially, it’s difficult to issue correct barriers because you don’t know at recording time what state a resource will be in.
They tried the approach where you add tiny fixup command lists between your real command lists, and found it really complicated to implement. And they tried not allowing threads to issue *any* barriers, but it wasn’t flexible enough.
Replying to
Later in the presentation, the presenter gives an example where adding a prefetch instruction actually slows the program down, just because it was bottlenecked on instruction fetch, and the additional prefetch instruction made that part worse.
The next section was about instruction retirement. This is the part that I thought was most interesting, because I don't know much about it. Instructions have to appear to complete (or "retire") in program order.
2/6
Replying to
So the whole chip is prefetching instructions and speculatively executing what they say, and then when the results are computed, they enter into the retire unit where they hang around until they are allowed to "retire" observably in program order.
The interesting thing here is that the retire unit only holds 64 entries, but fetching from memory takes 200 cycles at a minimum. That means we can't (even nearly!) hide memory latency by running concurrent ALU.
3/6
Replying to
So, if you're going to hit memory, you'll want to manually schedule either a) expensive instructions, or b) other memory operations, concurrently, to maximize parallelism of the chip. So interesting!!!
The previous diagram also lists the number of unnamed registers, which is less than I expected (72 and 64); I expected there would be hundreds. Interesting!
Another really interesting part: it turns out that interacting with the cache is done in transactions.
4/6
Replying to
@zeux@mastodon.gamedev.place 224 and 192, right
Replying to
@TomF@mastodon.gamedev.place
Oh, if I were tasked with this problem, I'd run the hardware counter approach on the target machine, not on my PC. (I assume the Jaguar has the relevant hardware counters.) The downside is my approach gets function-level accuracy, not line-level.
Re:performance the speaker of the presentation said it takes a few minutes per frame, which is actually totally do-able if you're only interested in a handful of representative frames.