Jukka Larja (roskakori2006.delete@this.gmail.com) on May 20, 2022 10:04 am wrote:
> Jan Wassenberg (jan.wassenberg.delete@this.gmail.com) on May 19, 2022 12:19 pm wrote:
> > Jukka Larja (roskakori2006.delete@this.gmail.com) on May 19, 2022 11:14 am wrote:
> > > Yeah, one man game studio. You can pick up pretty much any tech and make a game out of it.
> >
> > Fair point, it's not the most impressive example.
> > Here's a talk, mostly techniques rather than results, but
> > it does appear Insomniac Games used SIMD extensively.
> >
> > https://www.gdcvault.com/play/1022249/SIMD-at-Insomniac-Games-How
>
> Yeah, I've read those slides (they were maybe linked here previously, or I may even have read them sometime
> in 2015). Would be really interesting to know how they have used SIMD in their games (I'm not sure if
> the door example is real. I don't understand why they would need to test every door every time), though
> from comment 'Solves "death by a thousand cuts" problems', I think they have just very unusual amount
> of SIMD talent in-house. How else can you expect to SIMDify 1000 different places in code :D .
>
> -JLarja

That they're even trying it on "death by a thousand cuts" problems itself implies that the hot loops with any appropriate parallelism got this treatment long ago. Collision detection and culling are the ones I'm most familiar with, but at least animation has probably got some as well.

Here's one on culling: https://www.ea.com/frostbite/news/culling-the-battlefield-data-oriented-design-in-practice

As a gameplay programmer, you may never see this stuff; even if you're working on an engine, all of the most critical parts may be hidden from you in middleware like PhysX and Umbra.