Does software use energy directly, or indirectly?

Here’s a question for you. When you boot up a game on your console, your PC, or your mobile phone, what is actually happening? I think a basic description might be something like this. A game (like any software) starts with a series of instructions sent to the CPU, typically involving loading the program into physical memory (RAM), a process of retrieving the necessary game files, which it does by accessing the right location on a hard- or solid state drive, reading the bits of information stored there which can contain more instructions, data for things like textures, 3D geometry, shaders, and so on. Game files get loaded into RAM, and the process becomes almost infinitely complex, but essentially involves sending instructions back and forth to the CPU as required to manipulate and move data around in memory, send things to the GPU to compute and calculate triangles and rays to generate an image – all of the things that happen on screen that we functionally treat as the game software itself.

This entire process, of course, is inseparable from the hardware that has to act on and through all those different elements – the functions, the data and files I just described – and by being reliant on this hardware it requires the use of electrical power. There is no computation without electricity, most of which (I probably don’t need to remind you) we still generate from fossil fuel sources.

When the CPU receives the instruction to “read X region of the SSD and move it into RAM”, it uses the billions of transistor switches together with all the connected architecture of the system itself, from data busses on the motherboard, to high bandwidth PCI-express lanes, bridging hardware components to the CPU, to RAM and to storage. Doing this uses tiny voltage differences (0.8-1.4 Volts in the CPU - you wouldn’t even feel that if you stuck your tongue on it) to open, close, read, write, compare, add, multiply, transform, etc.

Now, let’s consider what happens to that hardware in the absence of the command to open the program. Certainly none of the above happens; probably something else? More often these days the hardware remains in an ‘idle’ state – CPU largely powered down, operating at maybe 1/10th of its maximum-clock speed (and thus using less electricity, doing things at a relatively glacial pace – because there just simply isnt much to do), or if it’s a more modern chip (like Apple silicon) it might even have certain “performance” cores switched off entirely. Background OS operations are probably still running, in their leisurely way. If we’re talking about a mobile phone, though, the difference might be even more stark, with the screen remaining off entirely, maybe even saving the lion’s share of power.

In other words, without software instructions… nothing happens. The hardware does not do anything on its own, without being told to – either by a user, by some program, or by background always-on operation as part of the OS on some sort of regular schedule.

Why is this illustration important? Surely this is obvious, and a broadly well-known story. Well, I’m emphasising it because there seems to be some debate or ambiguity in some places about whether or not software uses energy directly or if it is an indirect use of energy.

To unpack that distinction a bit more, and the implications of decisions around it, direct vs indirect energy consumption, here’s how the Greenhouse Gas Protocol describes it. This is taken from the GHG Protocol Scope 3 standard for accounting and allocating energy use (and associated GHG emissions) from the “use of sold products”. In our case, from the use of game software.

It doesn’t give an exact definition of what counts as direct vs indirect, but that seems fairly definitive. We can see that ‘web-based software’ is an example of the direct consumption of energy during use. I can’t think ‘web-based software’ would presents any particular challenge or difference from locally executed software either. Compare it tp the examples of indirect use that are quite physically distinct: clothing doesn’t consume electricity though the existence of a washing machine used to clean, even if some regime of cleaning and washing is sort of implied by the norms of clothing use. Food also needs no power to be usable as food, but the existence of refrigerators is ubiquitous, and so on.

I suspect the importance of the distinction between direct and indirect consumption boils down to whether or not major assumptions have to be relied upon to measure (or even estimate) the amounts of energy consumed. A lot rests on end-user habits with clothing, for instance. Does the owner of a garment was with hot water or cold water? Is the garment an under or outer layer? What is the right frequency of washes to assume? Does it change between a t-shirt and a trench coat? Similarly, with food, does a snack ice cream purchaser eat it immediately, or store it for later in the freezer? How long does the average ice cream stay in the freezer, relying on the fridge to keep it cold? These types of questions have no obvious common answer, would be onerous to try and measure or guess, and (by and large) their measurement would be of more academic interest than practical. What meaningful control does the seller of a t-shirt have over whether its buyer washes in hot or cold? Hardly any that I can see.

Contrast that with the use of software – first, there are direct measurements of discrete operations that can be measured and disclosed. Things like compute cycles, CPU utilisation rates, calls to servers, programs, libraries, functions and subfunctions, and software often has a wealth of internal metrics, minimum hardware requirements, expected rates of use, and so on that can be built or drawn upon. And compare the level of control or influence over these elements of the software – game companies can employ Eco Modes (catch the presentation about this from Ubisoft & Microsoft on the SGA Youtube if you missed it), and the Green Software Foundation has created the Software Carbon Intensity score, now adopted by the ISO as an official international standard.

So far, so good – software seems to directly use energy then, yes? Well, I tend to think so. But then I was thrown for a loop a bit, this week, as I was reading through the Science-Based Target Initiative’s (SBTi)draft of their V2 corporate standard and came across this bit of guidance about how the use of sold products in the ICT sector should be treated.

This in from "ANNEX C: SCOPE 3 ACCOUNTING", under Table C.2. Supplementary definition of the minimum boundary of direct and indirect use-phase emissions sources accounted for under scope 3 category 11 “use of sold products” (p.79). The importance of this guidance is that it determines what the required minimum inclusions are for companies that want their targets to be validated by the SBTi, and receive the organisation’s approval to claim to be in line with a scientifically grounded pathway towards a liveable planet, keeping warming to well below 2 degrees.

Here’s what SBTi says about the role of minimum boundaries for Scope 3 Category 11 use of sold products:

The minimum boundary includes the direct use-phase emissions of sold products over their expected lifetime (i.e. scope 1 and scope 2 emissions of end users that occur from the use of products that directly consume energy during use, fossil fuel and feedstock and GHGs and products that contain or form GHGs that are emitted during use).

The minimum boundary does not include indirect use-phase emissions that are generated by products that only consume energy indirectly during use over their expected lifetime. Indirect use-phase emissions are “optional”, but – if included – their calculation methodology shall be disclosed through the validation process.

Okay, let’s look at the top half of the table first. The table is meant to help us understand what counts as direct and indirect, what’s in and what’s out of the required minimum boundaries.

There’s our clothing example above – apparel washing and drying is “outside the minimum boundary” of emissions, just like in the GHG Protocol Scope 3 standard. Let’s continue down the table a bit further and check in on how the SBTi articulates the direct/indirect distinction for software.

Okay, that’s… a bit of a difference. For "software solution providers” (I think that’s as close as we’re going to get to a category that “games” belongs in) the minimum boundaries for S3.11 are only “Emissions from energy consumption of hardwares if sold by the same company providing the software”. Outside the minimum boundaries (and therefore “optional” to target setting and validation) is “Emissions from energy consumption of customer hardware running software or other IT infrastructure NOT sold by software provider.” From my reading, that would mean that only Sony, Microsoft and Nintendo would ever need to set targets for the energy use of their games and only for first-party titles. Huh?

I have got to be honest here – I do not understand this choice. To bring it back to the earlier example, the implication of the guidance is that SBTi is saying, in effect, that software doesn’t actually use energy directly it's the hardware that's using the energy. I just don’t see how that’s justifiable, and I’ve said so in my submission to the SBTi V2 public consultation process.

I should add, this is not actually a new proposed addition – it’s just a continuation of the same guidance in the (current) V1.2 SBTI standard (!).

Here, it’s spelled out even more explicitly. The SBTi thinks that software does not use energy directly, but indirectly. It must be hardware that uses energy – and while this is true, it's also a misunderstanding of the relationship between hardware and software. They are not two separate things – they are, functionally, the same process. Computational media theorist Friedrich Kittler went so far as to say that "There is no software" because "all code operations, despite such metaphoric faculties as call or return, come down to absolutely local string manipulations, that is... to signifiers of voltage differences." That's not setting up a binary opposition that software is pretend and hardware is real, it's to say they are the same thing.

In any case, in both the current V1.2 and future V2.0 standards, there are no examples of direct use of energy by software. Which is weird, because the carbon dioxide emissions into the atmosphere that they produce very much exist.

It’s possible that I’m misunderstanding something about the proposal here – but I don't think so. There's been some other strangeness around software and ICT at the SBTi. Did you know that there used to be an SBTi sector-specific guidance document for the ICT sector? It was published in 2020, and still exists on the website here, but it’s now just a “legacy” document, and an ICT sector pathway no longer appears on the website. I haven’t been able to find out why, and it’s really baffling. Perhaps the document was too narrow in its application – as the subtitle of the document indicates it’s for “Mobile Network Operators, Fixed Network Operators, and Data Centres Operators”, which again only touches on the hardware side of ICT.

But it’s weird to see it get retracted without a replacement, because it was produced by some really significant and important players: “The underlying methodologies and pathways were jointly developed by the Global Enabling Sustainability Initiative (GeSI), the GSMA, the International Telecommunication Union (ITU), and the Science Based Targets initiative (SBTi).” (p.8) These are important organisations.

One disappointing possibility might be that when it was published in 2020, the guidance laid out the following pathway for the sector. I've added lines to show what we should have expected in the five years since.

By this point, the entire ICT sector should be down about 20% give or take. I couldn’t find a “whole ICT sector emissions” graph to match see where we are today, but we can at least see how well the data centre part of the sector is going, by comparing it with the IEA’s recent report on Energy and AI.

There’s now about a 100 Mt gap between where it should be and where it is. Data centre emissions are just one part of the picture of sectoral ICT emissions. But I would be shocked if the trend of whole was lower than it was in 2020. It's certainly still risen in the games industry! Sure, we have some faster computers now, better bandwidths, more rays we can trace into a scene, and some large language models that spit out statically probable chains of words in a semi-useful manner, but the bottom line is climate-wrecking carbon pollution from software is getting worse, not better.

The SBTi is the closest thing we have to a gold standard in measuring ambition and action on reducing climate-destroying GHG emissions, and for good reason, it’s full of some of the world's brightest minds, and (usually) has very high standards. So it’s really confusing and disappointing to see what looks, to my interpretation, like a big hole in the integrity of targets. This stuff matters because these requirements and standards set how some of the largest companies in the world orient themselves towards climate action. It matters because this is one of the few ways we can pressure big corporates to act.

Games are software. If software doesn’t count as a direct use of energy, then it will be considered someone else’s responsibility to find ways to be efficient in its use. We know that game hardware is not going to deliver on this much – the makers themselves have told us so.

Hardware can only go so far. It sets the upper limits (and those can always be lower) but developers also have ways to optimise software to reduce power consumption below the maximums that any given hardware platform – whether a console a phones or a PCs – can consume. We have ways to minimise wasted activity where it doesn’t matter – and we will come up with even more in the future! But if there’s no incentive or requirement for software makers to put effort into meeting targets in this area, then these ideas will wither on the vine.

If you want to tell the SBTi to change its stance on indirect energy use from software like I did you can do so here. You don’t have to do the full survey (which is very long), you can just select to answer questions on “Target setting: Scope 3”. Remember to be polite, these people have a hard enough job as it is. If I'm wrong in my interpretation (always possible) then that ambiguity or confusion needs clearing up in the standard.

If you have more info on either why this approach was chosen by the SBTi, against almost every other organisation’s understanding, or where and why the ICT sector pathway guidance was removed, I would love to hear from you. I don’t think there’s a conspiracy here, but I do wonder whether the SBTi has a robust understanding of both the needs and the capacities of software development, an increasingly important part of our total emissions picture. Perhaps they have just had bigger fish to fry, but now’s the time to get it on the agenda.

As always, thanks for reading Greening the Games Industry. I have my annual hosting payment coming up for the servers that host this newsletter and send the emails. If you feel like chipping in, you can take out an annual subscription and it would help immensely.