Hacker News Reader

Comment by seritools | Hacker News Reader

PoE is one of the few games that actually makes use of lots and lots of cores/threads.

Any idea what for? I feel like PoE doesn't involve that much compute other than what would be offloading to the gpu. Maps are static, and I would have assumed that mobs are primarily computed server-side based on some sort of loosely synchronized state.

I guess I could imagine a few threads for managing different 'panes', a thread for chat, a thread for audio maybe? It's hard to think of 24 independent units of work.

I'm not a game dev, just used to play PoE and curious.

Could it be the gpu driver/framework? I thought DX12 and Vulkun were meant to be cpu optimised and be able to use heaps of cores.

I guess, but like... how? Like I said, I can't really think of 24 things to do lol. I'm reminded of Dolphin, the GC/Wii emulator - people would ask for more cores to be used and they'd basically be like "for what???", they started moving stuff like audio out, eventually they made some breakthroughs where they could split more things out.

Maybe with these frameworks threads are less dedicated and instead are more cooperative, idk. Really not my area!

Maybe all it does is produce crazy high, pointless FPS.

https://m.youtube.com/watch?v=MWyV0kIp5n4 I'm reminded of this poe build that can crash the server with too many spell effects

Or simply put, there's too much going on. I remember they had to rewrite ASAP some parts of the engine right after the release of Blight due to FPS drops down to 1/inf at the end-endgame versions of the encounter, as well as server crashes.

Sort of funny story, the concept of this build (spell loop) is currently meta, sadly the servers have improved to the point that they don‘t crash anymore.

I've seen the NVIDIA driver eat up all the CPU on multiple cores without really doing anything substantial to the framerate.

This was back in the Windows XP days when I was working on OpenGL and DirectX. It would do this while rendering like a couple of triangles. One core I could understand, but not all. I'm pretty sure the driver had some spinlocks in there.

I also managed to find out the NVIDIA driver assumed user buffers passed to OpenGL (VBOs) would be 16-byte aligned, using aligned SIMD operations on them directly, even though there's no mention of alignment in the OpenGL spec.

It just so happened that Microsoft's C++ runtime would do 16-byte aligned allocations, while the language I was using only did 4-byte.

All is fair in love and performance wars I suppose...

The trick used in AAA is to see each frame as an aggregation of core-independent jobs that can be queued up, and then to buffer several frames ahead. So you aren't working on just "frame A", but also finishing "frame B" and "frame C", and issuing the finished frames according to a desired pace, which allows you to effectively spend more time on single-threaded tasks.

The trade-off is that some number of frames of latency are now baked in by default, but if it means your game went from 30hz to 60hz with an frame of delay, it is about as responsive as it was before, but feels smoother.

Sure that explains the parallelization, but not why it takes 250 watts worth of compute to run the game. What's it computing?

The next frame.

if it's anything like gta5 it's going to be calling strlen a billionty times

Can you provide some more info about this?

Here's one writeup: https://arstechnica.com/gaming/2021/03/hacker-reduces-gta-on...

Reply on news.ycombinator.com