RiotTony

Hey Everyone. I'm a senior engineer at Riot and I specialise in performance issues.

Lets see if we can't get this fixed once and for all.

Most of the reports I've seen seem to be AMD related (some are Intel, but they may be different issues). The data I've seen from bad games looks to be independent of the game mode (happens in TFT and League) and isn't affecting just one portion of the game loop. This indicates that it's probably not due to Riot code.

Searching around even Fortnite seemed to be experiencing issues with a couple of drivers and Epic recommended rolling back to version 22.2.2 (https://www.amd.com/en/support/kb/release-notes/rn-rad-win-22-2-2) (This was from 22.5.1 and 22.6.1).

So, if you are experiencing the issue where the game s...

We do run a few third party libraries on other threads and do small amounts of work there already. The most work done on different threads is the particle simulation - that's pretty good, but we can still do a bit better there. As for porting game logic to more threads, that's quite tricky but definitely something we're thinking about for the future. As for multithreading the renderer, as we're still Dx9, that's not really an option.

The other thing we need to consider is min and mid spec support. There is no point making the game require 16 threads as we'd make the game run too slow on the lower spec machines. As 8 core machines become more popular, we'll be able to utilise them more, but for now we need to build for our player base.

Yeah. Sorry - ATM LoL was my favourite type of LoL too.

Sorry - it does mean that LoL won't work on Vista and XP. You'll need to upgrade your OS in order to keep playing.

And yes, this does mean that you'll no longer be able to play League on an ATM.

You are correct. We don't use one of the major commercial engines, we've rolled our own. This allows us to be more flexible - if we need something we can add it. We get to decide what the most important features are and what needs support. We also have had to build all of our tools (the game related ones at least. We still use 3rd party tools like Maya etc for art and audio and whatnot) - so our tools are customised to do what League needs: Creating particle effects, linking them to spells, dealing with game logic to name just a couple.

We are constantly iterating on our engine and tools so that we can more quickly and efficiently add new content. Of course, adding new content and features has a cost in terms of performance and memory, hence this eternal battle for framerate.

We don't test every skin of every champion on every spec machine on every game map or game type. There are just too many combinations there to do in a reasonable time with QA team. Even PBE doesn't catch every combination, which is why we need to keep an eye on live games and player reports for outliers. In this case, the Swain slow down wasn't flagged as an issue with our internal testing, or even on PBE. Either it wasn't noticeable enough (the impact would depend on screen resolution as well as GPU type and even the CPU could mitigate the GPU slowdown if it was slow enough) or it was deemed within the acceptible bounds of perf degradation or it wasn't seen.

So, to your question, it should have showed up in testing. If I was able to test on a min spec machine myself, it would have shown up. But my development machine is not min-spec (I do need to be able to compile the game), its more mid-spec and even on that machine it only showed up when I was running two game clients t...

There shouldn’t be any difference between a version on PBE and that same version on Live. If you are interested in figuring out why, there are some things we can do. Just PM me.

Thanks for noticing! We rolled out a nice optimisation with 8.13, so you should have noticed a good improvement in fps, particularly if your frame rate was already up around 80+fps.

We're constantly monitoring frame rates with each patch, and always looking for ways to speed up the slow parts of the code, and making sure we've not made things worse - hopefully we'll be able to roll out a few more optimisations that'll help even more over the coming patches.

Yup. That's pretty much it. As long as you have at least 2 cores, running 4 hyperthreads, CPU speed is the determinant factor. At the moment.

There is a lot more stuff in League now - not just graphical. We're dealing with entirely new systems - new abilities require new code and data. If you could run an old version of League you'd see the difference. It's come a long way.

You'll probably notice that nothing is at 100%, yet you're not able to hit an fps cap. That isn't supposed to happen.

Yeah, it is. A single thread doesn't lock to a single core - it will run on whatever core the system deems appropriate. If you run a single thread flat out, constantly, it will not use up one Core 100%, it will spread across all the available cores. If you have 8 cores, you'll see 12.5% utilisation.

I think the underlying concern here is that League isn't "Multi-threaded" enough. That we should be able to use 100% of all the available cores to maintain 144fps. And that is a fair concern - League does run on multiple threads and also uses multiple threads indirectly, but the core gameplay is mainly run on a single thread.

Now, one of the issues with multi threading is that it can increase latency - we're doing more at once, but all those things that are happening at once cannot be dependent on each other. We can't ...

Hi, I'm Tony and I'm a Rioter and I care about your FPS.

This is something we are working on and will continue to. We are constantly improving and updating League and a side effect of that is that things slow down as more things get added to the game. As we detect these slowdowns (ideally we catch these problems before they go live), we fix them, but sometimes the changes are so small, no one notices them. And when we have 100s of changes going in and some of them are imperceptibly slower, we can end up with a noticeable slow down with no obvious cause. It's death by a thousand paper cuts. These are hard to fix. All we can do is look at the performance of the game and look at the slowest parts, then try and optimise them. And we've already fixed all the low hanging fruit.

To optimise something, we first need to measure it. We've been sneakily adding in a lot of new performance measuring capabilities into the LIVE game so that we can accurately measure the performa...

He's right. That's not the way that Multi core CPUs work. A single thread will not run on just one core - it will jump across different cores, one at a time. On an 8 core system, one thread running at 100% can and probably will) look like 12.5% of your entire system. One individual core will not run flat out while the others are idling.

If you are bouncing between 70fps and 150fps, do you have "Wait For Vertical Sync" on? That can cause the game to drop from the monitor's frame rate to half that whenever the CPU dips even slightly below the monitors frame rate.

League is already partially multithreaded, although I'll be the first to admit that it could make far better use of more threads. It is something that we are working on - engine rework is ongoing, but with the game changing constantly, this is like rebuilding an airplane engine while its flying. We have to be very careful that we don't break anything as we go.

You have correctly surmised that the main performance issue is a CPU bottleneck - in a team fight we're dealing with a lot of particles, and this can be costly. In fact, there is a break down of the rendering pipeline here which will g...

Yeah, there are ways around the virtual overhead, but the benefit of virtuals are that you don't need to know what it is that you're calling a given function on. Most use cases are just that - a collection of objects that are similar, but different enough to warrant different implementations of some of their parts. Another way to mitigate the cost of virtuals is to sort them by type. In that case you have far fewer I and D cache misses as you're usually calling the same functions. Modern HW is smart enough to predict the repeated branches.

Depends on what you want to do there. If you want to do performance optimisation, then yeah, you'll should know it or be able to learn it on the job. But most of an engineers work is much higher level than this. Having said that, every engineer should be able to measure the performance of their code and understand how to speed it up if needed.

If your CS major isn't teaching yourself anything useful, you can always teach yourself. There is so much information out there for budding programmers and the best way to learn is to do. Build systems, write code for yourself. The more you code, the better you get.

There is a surprising amount of work going on in there: scaling, compositing, updating, animating - lots of triangles, lots of textures. That was not a release build either, so there is some extra work going on in there that doesn't happen in LIVE builds.

I agree though, it is a considerable portion of the frame and while some work has been done since that screen shot to improve that, there is more that we should be able to do to in the future.

I totally agree that a programmer shouldn't limit themselves to a single language - the more you know, the more you know. And yes, Riot does use other languages in different roles.

The assembly is there to illustrate the cause of the slowdowns - you very rarely (if ever) need to drop down the assembly on modern HW, but it does help to understand what is going on under the hood which can in turn help you to write more performant code at the top level.

Are you playing fullscreen, windowed or borderless? And at what resolution and quality?