At the time, the world of CPUs was honestly not very interesting, at least in terms of the competitive landscape. The answer to “which CPU should I get?” was, for a long period, an Intel processor of some sort—probably a Core i5 or i7. Intel was ticking and tocking along, delivering worthwhile improvements to its CPUs via process tech and architectural updates on an annual cadence. AMD and others in the market couldn’t keep up.

This fact made the business of publishing CPU reviews rather challenging, as you might imagine. Nobody really needed a comparative review to make a buying decision. On the GPU side of things, a similar dynamic was playing out with Nvidia’s dominance in graphics.

Then a funny thing happened. My last CPU review for The Tech Report was the then-new Intel Skylake processor fabricated on a 14-nm process. Shortly after that, I went to work at AMD and stayed there for five years. I then took a job at Intel, in its graphics division. When I walked in the door there, Intel was still shipping 14-nm Skylake processors as its primary consumer products—somewhat revised, but fundamentally the same.

For five years, the ticks and tocks had stopped cold.

Eventually, in place of Intel’s singular dominance, a broad constellation of alternatives flourished. Fast forward to today, and the consumer CPU landscape is more interesting than ever. There are more competitors and a broader variety of technologies on offer. Yes, recent supply constraints have put a damper on things to some extent, but this, too, shall pass.

Of course, we don’t call them CPUs anymore. These products are now called SoCs, or systems on a chip.

Oddly enough, CPUs weren’t really just CPUs for a very long time—they integrated FPUs, memory controllers, last-level caches, and I/O interfaces before folks embraced the SoC label. Now, SoCs are no longer just systems on a chip, either; many of these products involve packaging together multiple chips and perhaps memory, as well.

Whatever you call them, though, they are at an intriguing place in their evolution. Some of these products are so capable and refined that they’ve turned traditionally challenging personal-computing workloads into solved problems. Meanwhile, the challenge of running generative-AI inference locally is driving a new generation of big SoCs with unified memory. I’ve already written about how I think those big SoCs are going to keep growing and may supplant traditional graphics cards for a lot of gamers and enthusiasts. In my version of events, this is a Good Thing for all involved.

So many open questions

You probably know the key players in the PC SoC race: Apple, AMD, Intel, Nvidia (with buddy MediaTek), and Qualcomm. (Eventually, Samsung might get in on the action, and possibly another dark horse like Huawei.) Each of them has some version of each of the key IPs needed to build an SoC, and they all have products shipping in systems now, with further plans on their roadmaps.

They face a host of fascinating decisions as they figure out what to do next, and I expect some of their choices to differ substantially from one another. The more compelling questions include:

What scale and component mix? — This is the most obvious one, and I’ve already alluded to the rise of big SoCs with large and fast GPUs and memory subsystems. Apple has thrown down the gauntlet yet again with the M5 Ultra. Who else will step up and compete there? And how will folks vary the mix of capabilities at different product scales?

What to do about CPU cores? — After some relative stagnation, we’ve seen real progress on per-thread performance in recent years. In the period before that, PC processors arguably had too many cores and too few advances in per-thread performance—in part because the primary development target for many CPU cores was server chips, which live in a different, more thread-parallel sort of world.

The most obvious indicator of this problem, in my view, was the unbelievable prominence of Cinebench scores in marketing materials as an indicator of consumer CPU performance. Please, show me again how good your CPU is at doing a GPU’s job. I always enjoy graphics rendering work measured in seconds per frame.

Meanwhile, Amdahl’s Law is undefeated.

Fortunately, new cores have moved the needle on IPC and per-thread perf, and I am here for it.

Another still-open question is what, exactly, to do with heterogeneous CPU cores or asymmetric multiprocessing. Most silicon providers seem to believe that offering different core types makes sense for efficiency, at least in some cases, but the solutions on offer differ substantially.

NPUs, GPUs, or both? — The NPUs in today’s PC chips have evolved to handle at least some generative AI workloads, but many of them have their roots in running small networks efficiently for real-time workloads like face detection for mobile device cameras. NPUs themselves are typically smaller and more efficient than GPUs, but they have limitations in terms of flexibility and supported operation types. In order to handle future AI workloads, NPUs will have to add more general computing chops. In doing so, will they lose their efficiency advantages over GPUs?

Bigger picture, does it make sense for NPUs and GPUs to coexist? If so, what is the mix of work that gets assigned to each one?

What happens with packaging? — Multiple chips from different fabs sharing a package, the stacking of chips on top of one another, various vertical interconnect technologies, and all sorts of related voodoo make this space one to watch. Each player seems to have its own set of technologies on this front, and they are wildly differentiated from one another.

How will traditional barriers erode? — Some structural dynamics in the PC market have changed thanks to software translation and compatibility layers, and more change is coming. Apple moved from x86 to Arm with few hiccups, and Qualcomm now ships competitive Windows laptops with Arm cores. PC gamers run Windows games in Linux on the regular. The rise of agentic AI coding tools may erode such barriers further, making the work of, say, porting PC games to macOS or Linux trivial and common. Something tells me things will get truly freaky on this front soon, with unforeseeable consequences.

Those are just a few of the questions in play today. The choices the silicon providers make in navigating them will be consequential. Past me would be kind of jealous.

Let’s take a tour

As long as I keep doing this Damage Labs thing, I get to cover some of the drama in this new era of consumer SoCs. But I have been distracted and preoccupied by corporate work and crazy hobbies for a while now. I kind of need to write myself into shape and better familiarize myself with some details of the current landscape.

To make that happen, I have cooked up a hare-brained plan to review each of the major PC SoC makers, one by one. My intention is to review their current offerings and to look a little closer at the key types of IP they possess.

At first blush, I’d say the categories to be covered for each firm will be something like this:

• CPU cores

• GPU

• NPU

• SoC integration—glue, cache, interconnects, etc.

• Memory

• Packaging

• Fabrication tech

• Software and ecosystems

That may or may not cover it, but hopefully it’s a reasonable template to get us started. My vision for this is one article per SoC maker, but that’s a ton of ground to cover. I guess we’ll see what happens. If you’re at all interested, please take a moment to subscribe—and perhaps even share with a friend. Thanks!

Subscribe now

Share

One of the joys of the years since I left journalism for the tech industry has been finding space in my life for hobbies. Back when I was running The Tech Report, I had made my hobby into my job. Can’t say I recommend that, in some ways. There wasn’t a lot of extra room—or money—in my life for much else. Between work and family obligations, I had no space for other activities and, honestly, not quite enough space for the family side of things.

Working a corporate job requires some long hours, but it’s honestly nothing next to how I worked myself as a reviewer. So after a little bit of adjustment to something like a normal work schedule, I was able to embrace some hobbies.

And, well, look out.

Like a lot of folks with, uh, nerd-adjacent inclinations, I can get pretty deep down a rabbit hole in a hurry. I fell hard into building mechanical keyboards some years ago and now have a crazy collection of those. But my most recent enthusiasm, in the past few years, is high-power amateur rocketry.

Like a rocket

I got into this one almost accidentally, by accommodating my two younger sons’ childhood interest in rockets. The second son in particular is given to enthusiasms, and rockets were very much on his agenda. So we pulled an old Estes model rocket kit off of the shelf, found a spot to launch it, and gave it a shot. Soon, we were building new model kits and looking for local clubs with more space to launch.

That was good fun, but nothing we did there prepared us for when, almost on a lark, I took the boys to an event called AirFest that happens annually in, well, a giant empty field in south-central Kansas affectionately known as The Rocket Pasture. After harvest each year, this vast, open space is an ideal location for hobbyists to practice amateur rocketry without worrying too much about a wayward rocket landing on something in a bad way. The local club, known as Kloudbusters, regularly gets a waiver from the FAA for flights to altitudes as high as 50,000 feet, and people come from all over the nation—and even from other countries—to launch rockets there. It’s one of the premier launch sites of its type anywhere, and it’s just under four hours’ drive from our house outside of Kansas City.

I still remember the first impression upon getting out of our car around 10 a.m. on Saturday morning, about four years ago, with the launch already underway. As we walked from the car to the launch area, the voice on the loudspeaker announced a series of flights—with the name of the flyer, the type of rocket, the type of motor, and maybe a sense of what to expect—and one by one, the rockets took off spitting flames of red, blue, and green and reaching sometimes ridiculous velocities and extreme altitudes in seconds.

Occasionally, everything would slow down as the announcer would direct the crowd’s attention to a more distant launch pad, and then a much larger rocket on an enormous motor would take off with a giant plume of smoke and a sound similar to a jetliner’s.

The boys and I were transfixed.

We’d brought our own model rockets to launch, such as they were, but we sat there enthralled by watching these people enjoying an obviously more advanced form of the technology.

I remember at one point walking across the open range to recover one of my sons’ rockets and thinking to myself that moving was oddly somehow more difficult than it should be. I didn’t register why until, at the end of the day, I returned to my car and saw a temperature reading of something like 102°F (~39°C). I was too captivated by the whole experience for the fact of the extreme heat to fully register.

What followed was a quick series of steps down the rabbit hole. By the next AirFest, I was flying a Level 1 high-power certification flight, and my second son was flying his junior high-power cert flight, both on rockets we’d built for that purpose. Next spring came my L2 certification on an even larger motor, along with rocket builds that delved first into altimeter-based parachute deployment and then two-stage flights with electronic air starts. At our third AirFest, my youngest son got his junior high-power certification, as well. That meant that anything I could fly, the two boys could fly, too, under my supervision.

To get there, we developed proficiencies in various arts of rocket fabrication, simulation tools, 3D printing, electronics soldering and assembly, remote telemetry and tracking, handling black powder deployment charges, spray painting, and so forth. (And sanding. So much sanding.) The learning curve was steep but exciting, and the resulting flights were typically rewarding. We flew rockets a mile high or more at speeds nearing Mach 1 and recovered them successfully. Even the failures were learning opportunities, so long as we kept things in the proper context.

New materials for new frontiers

Late last year, the time came to decide on our projects for AirFest 2026. Up until then, most of the rockets we’d built were constructed from cardboard with plywood fins and plastic nose cones. Those materials are cheap, light, and relatively sturdy, so they make sense for everything from a tiny Estes model rocket to a five-foot-tall high-power kit like the one I used to get my L1 and L2 certifications.

But such materials aren’t always robust enough to handle the forces involved in flights to Mach 1 and beyond. And that’s exactly the sort of flights that my second son and I wanted to attempt next. As we’d done in the past, we decided to build similar rockets and fly them independently, with a little cross-team support where needed. (The youngest, who is a bit behind us progress-wise, started work on a rocket with electronic dual deployment.)

We decided to build our new rockets from fiberglass components provided in kits by Wildman Rocketry. Both rockets would be roughly seven feet long with a lower section, an electronics bay, an upper tube or payload section, and a nose cone—all fiberglass save for the aluminum tip of the nose cone. I chose a Wildman Drago 3XL kit for my build, and my son decided on a 3” DarkStar, which looks cooler but is more complicated to build due to its fancy dual-fin setup.

These kits come with 54-mm-wide motor mounts capable of accommodating relatively large motors.

To give you a sense of context, let’s talk briefly about rocket motor sizes. The typical Estes rocket you may have seen launched in a park or in Boy Scouts has an 18-mm motor mount and a motor rated in the “C” impulse class. Impulse is the total thrust over time created by the motor. The impulse classification system is based on letters in alphabetical order. The upper limit of each successive classification range is twice that of the previous class. So a D motor can have twice the total impulse of a C, an E motor can offer twice the total impulse of a D, and so forth.

Our plan was to fly K and L motors in these rockets. We estimated that the larger of the two, an Aerotech L1000W, should take one of these rockets to around 12,000 feet above ground level at a peak speed of around Mach 1.4—or over 1,000 miles per hour.

Which, I mean, is awesome.

The project of building these rockets turned out to be fairly complex, even though I thought I knew what I was getting into. When you’re putting an object this large, sturdy, and pointy into the air at high speeds, there’s some added responsibility to make sure nothing goes horribly wrong. In our case, that meant working to ensure robust construction and strong bonding with unfamiliar materials, as well as assembling a more complex set of avionics systems with true redundancy.

I won’t go too far into the details of the build process, but as I said before, there’s a lot of sanding and surface prep, which is basically just getting everything ready for bonding with epoxy.

Here’s a quick look at one of the more interesting building steps, which is assembling the “fin can” section. You’re basically fitting the fins into pre-cut slits in the body tube and using epoxy to hold them in place. We chose to use JB Weld for this purpose, since it’s easy to work with and widely available.

As you can see below, I masked off the appropriate areas, applied big globs of epoxy, and dragged a large socket through it to create big, beefy fillets between the fins and the body tube.

In addition to the fiberglass tubes provided in the kit, building a rocket like this one involves one or two fabric parachutes, some Nomex parachute protectors (just squares of fireproof fabric), and lots of Kevlar cord. It also involves a fair amount of metal hardware, typically 1/4” bolts and such. We paid our visits to The Home Depot and got it all sorted.

Building the rocket’s brain

The basic flight plan for this sort of rocket is just an up-and-down arc, with a couple of events in the middle.

The first event happens at the top of the arc, right as the rocket reaches the apogee of its flight and begins to arc over. The rocket should be moving slowly at this point, and we take advantage of that opportunity to fire a black-powder charge. This charge separates the lower portion of the rocket from the upper section, preventing the intact rocket from arcing over and accelerating nose-first downward. Instead, the rocket should tumble down from apogee, aided in this case by a small, 18”-wide parachute called a drogue. The point of the drogue is to slow the rocket’s descent but not too much. Deploying a full-size parachute at high altitude can cause a rocket to drift miles away in the wind.

The second event is the deployment of the main chute, which in our rockets is 40” wide and housed in the upper payload section, just below the nose cone. I programmed my altimeter to fire the charge to eject the nose cone and deploy that chute at 700 feet off the ground—long enough for the parachute to unfold and catch the air, further slowing the rocket’s descent before it hits the ground.

The key to making those things happen is the avionics bay, a cylindrical section that lives in the center of the rocket.

This thing is both the brains and the backbone of the whole operation. It houses all of our electronics, of course. It also connects the lower and upper tubes of the rocket together, and the Kevlar cords of the upper and lower recovery harnesses also connect to it.

On both the fore and aft bulkheads are 3D-printed charge wells that house the black-powder charges meant to deploy the parachutes. In this case, there are two charges on each bulkhead, since we have redundant altimeters. Snaking up from the inside of the electronics bay into the charge wells are the wires for e-matches, the low-voltage incendiary devices that ignite the black-powder charges.

The first altimeter is set to fire a charge at a given point, and the backup altimeter is programmed to fire a slightly larger charge about a second later, just to make sure the chutes deploy. In the grim calculus of failure avoidance, we’d rather blow up the rocket than allow it to come down in a ballistic arc at high velocity.

Inside are three electronic devices. The main altimeter, an Eggtimer Quasar pictured at the top above, controls the primary deployment charges. It collects telemetry data that it both stores and relays to our hand-held base station on the ground. The Quasar also has a GPS/GNSS receiver, and it sends its position data back to the base, as well.

I like Eggtimer’s altimeters generally, but they are sold as kits and require some soldering. Building a Quasar involves soldering tiny SMT components. I got through it, but I can’t recommend it as a fun way to spend an evening.

On the lower left is an Eggtimer Quark, our backup altimeter. The Quark is dead simple, programmed via jumpers on the board, and only exists to fire our two backup charges.

On the lower right is a Heltec Mesh Node T096 with Meshtastic firmware installed that I’m using as a GPS-based tracking device. Meshtastic devices combine 900 MHz-class low-power long-range radio (LoRa) transceivers with open-source firmware meant to enable a mesh-based repeater network for low-bandwidth communication. Think off-grid texting during the zombie apocalypse. There’s a whole ecosystem of Meshtastic devices and kits, and tinkering with them is a hobby in itself. Folks build nodes with big antennas and solar power, mount them up high, and cooperatively create an independent network. Kind of nifty.

This Heltec product has built-in GPS/GNSS reception, Bluetooth, and an external antenna for 900 MHz LoRa, all in a tiny package that fits easily even into small rockets.

Meshtastic trackers haven’t been too widely used in amateur rocketry, but we’ve found them to be quite effective when configured properly. We have another node that we use as a base; it connects to a phone via Bluetooth and shows info in the Meshtastic app. The range for 900 MHz LoRa is quite good with line of sight, and you almost always have that when a rocket is in the sky. Even if it’s hidden over a ridge when it has landed, you can just go to the last known position, and you should be close. If worst comes to worst, any other Meshtastic nodes in the area—or on a nearby rocket in the sky—can act as a repeater to send packets containing position info back to the base.

Also, notably, we can get a tracker and battery setup for under 50 bucks, which is way less than most custom rocket-tracking solutions. Given how many tracking devices we’ve sacrificed to, uh, kinetic events involving a rocket meeting the ground, there’s an appeal to affordable solutions.

On the underside of the sled in the avionics bay are the LiPo batteries for the three devices plus an orange pull-pin switch. The purpose of this switch is to allow us to arm the rocket’s electronics—and their black-powder charges—right before the flight. When the pin is inserted in the switch, no power flows to the electronics. When it’s pulled out, everything lights up. This arrangement prevents inadvertent firing of deployment charges when a rocket is being safety inspected or getting mounted on a launch rail.

Setbacks and successes

Both my son and I got our fiberglass rockets built and ready for this year’s AirFest. I’d like to say that we took the rockets out to the launch site, had no issues, and flew them. With projects this complicated, though, that’s never how it happens.

We hit a few notable snags along the way.

The first has to do with those black-powder charges. For our prior rockets, we used a black-powder substitute that’s easier to source and to clean up, but it requires really good containment in order to, uhh, explode well. This issue can be exacerbated by the lower atmospheric pressure at high altitudes. Black powder is better on this front, so it is almost exclusively used in amateur rocketry. We also needed to figure out the correct amount of black powder—or substitute—to use in our rockets’ four charge wells. None of these issues are insurmountable or even terribly difficult, but several days before AirFest, we had not worked out the sizing and were not in possession of any real black powder, nor did we have a confirmed place to buy it.

In the end, we tracked down some real black powder from a vendor at AirFest and wound up conducting our final ground-based deployment tests—basically test-firing the charges to make sure the rocket separates—on the range out at the rocket pasture.

This setup led to a scene where we attempted a test with ~1.5 grams of powder, the rocket did not separate, and Tim Lehr—the Wildman of Wildman Rocketry—was watching. He immediately asked us how much powder we used and told us to double it. “I built that rocket. I know what it can take.” No point in arguing with the Wildman, we quickly decided, and that advice helped us finalize our charge setups.

Our plan was for my son to fly his fiberglass rocket first, and then I’d fly mine after that. The first flight for each rocket would be on the smaller K motor, and if that went well, we’d move up to the L1000W.

When we put my son’s rocket up on the rail for its first flight and pulled out the pin to turn on the electronics, though, things got wonky. The telemetry readings coming from our handheld base seemed very much off. It was reporting high altitudes while the rocket was sitting stationary on the launch pad. We turned everything off, took the rocket off the rack, fiddled with some settings to make sure the base wasn’t getting readings from someone else’s rocket, and tried it all again. This time, the altimeter wound up firing the charge for the drogue deployment while the rocket was sitting on the rail.

Which is not ideal.

Near as I can tell, the problem was a bad altimeter or pressure sensor. We are still working with the Eggtimer folks on a post-mortem.

Our solution was to swap out the Eggtimer Quantum in my son’s rocket for the one from my rocket. That altimeter worked as expected, and…

His rocket flew to around 6,400 feet above ground level on the K motor. The whole flight couldn’t have gone much better. The parachutes deployed as planned, and we recovered the rocket in a nearby field, intact and ready to be flown again.

My youngest son also successfully flew his first rocket with electronic dual deployment on an H motor that day. It’s basically a smaller version of our rockets made out of cardboard with a similar altimeter-based deployment setup.

That afternoon, though, I found a problem with my rocket that killed my chances of flying: the pull-pin switch had failed. I could slide the pin into the mechanism, but the switches would not turn off the power to the altimeters. A key piece of safety equipment on the rocket wasn’t working.

I bought this switch from a vendor known as Inverted Pursuits, and happily, they had a booth at AirFest. (Rocketry is a small world, and AirFest is a big event.) I took the switch over and explained the problem. The guy at the booth basically said “my bad” and gave me a replacement. That evening, I set up my soldering equipment in our AirBnB and soldered in a new switch.

The next day, when it came time for my son to fly his fiberglass rocket on the L motor, we discovered that his identical pull-pin switch failed just like mine had. The fix was for my rocket to donate the full guts of its avionics bay to my son’s rocket for its second flight.

We quickly swapped the avionics sled in, and his rocket flew to 11,000 feet. Again, the whole flight went well, including deployment and recovery. My younger son also flew his dual-deploy rocket again, on a larger I motor to 3,700 feet, and we successfully recovered it.

By then, as you might imagine, I was incredibly proud of what my sons had accomplished at ages 17 and 14. Whatever else happened, our AirFest ‘26 projects were a resounding success.

My turn

Still, I get a kick out of flying my own rockets, and on day three, I finally got to launch my rocket on the K motor. Here’s how that looked:

And a video of the launch:

My 17-year-old captured most of these sweet launch photos. He also got a shot of the rocket on its descent after deployment of the main chute.

One of the things I enjoy about a launch is when all of the various systems in the rocket work together as planned to enable launch, flight, deployment, tracking, and recovery. As the rocket’s in the sky, real-time telemetry tells us what’s happening with the altitude and deployment events. Meanwhile, the GPS tracker does its thing. Here’s a look at the GPS position log from the Meshtastic app during my flight.

And here’s a screenshot from the map view in the Meshtastic app that I took during one of our recoveries.

“T096” is our tracker device, and the blue dot is my phone. At this point, we were walking out to pick up the rocket. That’s easier to do when you get a satellite view of exactly where the thing landed.

This is how my rocket looked when we got to it. The Kevlar cords holding it together are really long for at least two reasons: to allow the shock of the deployment charges to dissipate when the sections of the rocket pop apart, and to ensure that no two pieces of the rocket bang into each other during the descent under chute.

Above is the flight summary from my primary altimeter. Apogee was 7,110 feet above ground level, a bit higher than my son’s rocket on the same type of motor, probably since his fancy dual fins add a bit more drag. The max velocity was 880 feet per second or 600 miles per hour. That’s subsonic, which is what we expected with this K353W motor. Average acceleration was 9.76 Gs.

The rocket nosed over at 7,089 feet, at which point the charge fired to deploy the drogue parachute, while the main-chute charge fired at 695 feet.

So it all went very well indeed.

The next step for me will be to fly this rocket on the L1000W motor, possibly at a launch event in November. A simulation predicts roughly 26 Gs of acceleration, speeds in excess of 1,000 mph or Mach 1.3, and over 12,000 feet of altitude.

After that, we’re already contemplating our next steps for AirFest 2027. Wildman sells a smaller fiberglass kit that can go to over 20,000 feet on an L motor, if you’re willing to work in some tight confines. And there’s always Level 3 high-power certification, which unlocks access to M and higher motors. Hmm.

My own desktop sports a pair of massive, 4K HDR displays, a custom mechanical keyboard, a sit-stand desk, custom bookshelf speakers and an amp, a Herman Miller chair, a nice microphone, and a Sony mirrorless camera acting indulgently as my webcam. In this regard, I am not an outlier. One can pop on to reddit’s r/battlestations and see an incredible collection of similar setups, most of which are more tastefully arranged than my own. From content creation to remote work to gaming and more, desktop computing is still very much in demand, and folks are still building elaborate systems—and full desk setups—to make it possible.

So when I have something to say about the decline of one aspect of the PC ecosystem, my instinct is to step carefully.

Still, I have been struck lately by an impression that seems simultaneously rather obvious and yet impossible: that Microsoft is losing the consumer PC market with Windows. Like that overused Hemingway quotation about how one goes bankrupt—Windows may be losing the consumer market two ways: gradually, then suddenly.

The gradually part has been apparent for years, of course. There is a long, unfortunate history of Windows being mismanaged on many fronts. But lately, it feels like the Windows sled is cresting the hill of decline, and the sudden plunge downward is coming.

A story about reaping and sowing

Microsoft has a storied history of competing with software developers who tried to build on its Windows platform. One of the last major attempts, in my view, happened a decade ago when both Oculus and Valve tried to build VR gaming businesses based on Windows PCs. The trajectory of that particular episode was laughably predictable at the time. Microsoft ramped up its own Windows MR effort, sapped the enthusiasm from SteamVR and Oculus, and then abandoned the Windows MR ecosystem before it was ever even half baked.

Practically everyone saw that mess coming before it happened. Regardless of VR’s challenges with broad consumer appeal, the whole situation was an object lesson for anyone paying attention. Why would any third party build a new business that relies on Microsoft’s Windows platform? I don’t think there has been a good answer to that question for a decade or so.

Some of these episodes have very long tails. Valve and Oculus (which became Meta) learned their lessons. Meta shifted its VR efforts to standalone headsets running an Android-derived OS. Valve, meanwhile, saw the threat not just to SteamVR but to the entire Steam store from Microsoft’s own initiatives. So it continued investing in the work that became a collection of enabling technologies for PC gaming—and its whole Steam ecosystem—to move away from reliance on Windows.

Enhancements to Linux compatibility tools like Proton and the DXVK graphics compatibility layer eventually led to the successful release of the Steam Deck. With a relatively modest GPU, that system is capable of running quite a few games well—in part because DXVK’s graphics API translations to Vulkan proved more effective at avoiding frame-time spikes than Microsoft’s own native Direct3D implementation on Windows.

Today, Valve offers the Linux-based Steam Machine as a home gaming console, while the just-released Steam Frame headset continues Valve’s long commitment to consumer VR hardware—many years after Microsoft quit on Windows MR.

Valve has also invested in the FEX emulator for Linux that allows x86 and x64 programs to run on Arm CPUs. With Proton, DXVK, and FEX working together, Steam Frame headsets running Linux on Arm SoCs can run some SteamVR games for Windows locally on the headset. Performance is still a limiting factor, of course, but the reality remains: the software infrastructure exists to run PC games—even latency-sensitive VR games, of all things—entirely outside of the traditional Wintel ecosystem.

PC gaming, once the premier application that ensured lock-in to x86 hardware and the Windows OS, has become a portable capability on Linux thanks to compatibility layers funded in part by Valve.

Long tail, indeed.

Momentum

This is just one of many such stories. One or two of them alone would be unfortunate for the future of the Windows platform, but taken together, they feel like so many pebbles tumbling down the hill that presage the start of a much larger avalanche. A tiny stone here or there might be nothing much, but they sure seem to be accumulating at an alarming, accelerating rate.

Some of the problem is rot within Windows itself.

My family used a Windows 10 system to drive our TV for years. It was nice because we could stream from any service and play PC games on a single system, never having to swap inputs. Also, having a real keyboard for search is excellent. Late last year, I built a new Windows 11 HTPC and also upgraded to a nifty new TV with 4K HDR, wide color gamut, high refresh rates, and so forth. Seemed like a natural upgrade on both fronts.

Turns out, however, that most video streaming services simply do not support 4K HDR video streaming to Windows 11. I was shocked. That means no Windows-based laptop, desktop, or tablet can play premium video formats from HBO Max, Disney+, and so forth. (Some progress has been made recently on Netflix and Apple TV+, but the picture otherwise is dire.) More importantly, that means Microsoft has not put sufficient effort into the technology and relationships required to ensure proper premium-format video support from the streamers.

Our solution was to buy an Apple TV 4K and live with input swapping. The Apple TV streams everything well.

Despite the fact that Microsoft has a digital rights regime for Windows registration and increasingly unavoidable requirements for online user accounts—and that these measures would seem to work to limit OS piracy—as a Windows user, one increasingly feels more like the product than the customer.

After every major Windows update, once or twice a year on each system, I have done the dance of hitting decline-decline-next in order to refuse the Office 365 sign-up, only to be greeted with aggressive shilling for Edge.

Search from the Start menu used to be a reliable way to launch programs. Then it became a menu that produced web results when I typed the name of an installed application into the search field. Now it may also inadvertently launch some ill-conceived Copilot feature no one wants.

I had another example, but Windows rebooted to install an update before I could finish writing it out, and I forgot. You get the idea, though.

One gets the sense the decay has been accelerating.

Meanwhile, I’ve spent a little time with Macs lately, and the logically organized settings app that mirrors what I see on my iPhone makes using macOS feel familiar despite my inexperience with it. Contrast that with the multi-layered geological sedimentation that is Windows settings. The modern settings application has limited functionality. Beneath it are various control panel layers and dialogs dating from Windows 10 through Vista and all the way back to NT4. Ever has it been, and apparently, ever shall it be.

Some larger rocks join the mix

The situation grew more alarming when a bigger rock came bounding down the hill in the form of the MacBook Neo launch this past spring. Sure, you’d have seen 90% MacBooks in a typical U.S. coffee shop for years. But Apple always stayed upmarket with its MacBooks, ceding the lower end of the market to everyone else. With the Neo, Apple chose to use its iPhone chips to build affordable laptops at scale—and had an instant hit on its hands. The Neo looks to me like a much nicer system than the competing offerings from the likes of HP, Lenovo, and others. Odds are that Apple will eat up a sizeable chunk of the laptop market with the Neo and its successors.

I expect this development would be a bigger story if not for the insane AI hardware crunch affecting the entire computing market. Even in that context, though, the Neo poses a threat. A laptop config with 8 GB of RAM, if unfortunately necessary, is probably somewhat more workable on a Mac than on Windows thanks to macOS’s more efficient use of memory.

Why Windows, really?

In the larger picture, it’s hard to see how Windows could completely lose the consumer market, one it has dominated for many years. But if enough rocks get enough momentum at once, the question will get answered definitively.

Also, well, what will stop this trend?

My sense is that Microsoft has no compelling vision for the future of Windows. To this day, they’ve offered no clear sense of how the OS can work well on touch-screen devices. And we have no good set of reasons why consumers ought to prefer Windows-based systems to the alternatives.

The Office suite used to be part of that answer, but that argument has little resonance with a generation raised on Google Docs and other browser-based apps. Meanwhile, the vast majority of AI development—and local AI tinkering among enthusiasts—is happening on Linux.

Put another way: who is rooting for Windows? Even PC enthusiasts and gamers don’t seem to be any longer. Many appear to be looking for an exit, contemplating a move to Linux or a Mac, if they haven’t already made such a move. I may not step away from Windows entirely anytime soon, but my own path as an enthusiast and gamer is likely to involve more Linux, maybe more macOS, and more purpose-built solutions like the Apple TV going forward.

It almost seems as if Microsoft’s chokehold on PC gaming now rests almost entirely on specific problems, like Linux compatibility with anti-cheat software, that could be resolved if game publishers start taking the Steam Machine seriously.

Sure, corporate laptops may stick with Windows for a while, but that is not a consumer market. The obvious trajectory there is that users at firms with BYOD policies will simply choose other options, and Windows’ share of that market will continue eroding. Eventually, if enough consumers reject Windows, corporate IT departments will have to accommodate their users’ preferences, too.

More than any single other factor, the vibes are simply not good. The recent, slow decline of Windows may soon turn into something more severe, because there is precious little preventing the slide. Oddly, if and when that happens, I’m not sure anyone outside of Redmond will mind much at all.

It’s easy to look at the situation today and be glum. But I have a few reasons to be optimistic in spite of it all.

For one thing, the present moment isn’t entirely unprecedented. We’ve had two prior waves of demand—driven by cryptocurrency mining—hoovering up all of the high-end consumer GPUs, and we got through that. I think Jensen Huang is right to cite a sort of Jevons paradox situation for GPUs: as the cost per flop of data-parallel computing power decreases, demand rises. That dynamic has held true essentially since the birth of the GPU, and it’s a great thing for the computing market overall. The other side of that coin is that supply will rise to meet demand, made possible by the rising prices that fund the build-out of manufacturing capacity—eventually. Also, the bottom could drop out of the AI data center bubble, and we could find ourselves laughing maniacally while bathing in stacks of cheap DRAM and flash chips in a couple of years.

Regardless of how it all goes down, I believe the PC market will come out of the current moment transformed.

AI inference as the impetus

If, like Jensen Huang and, uh, maybe the pope, you believe open-weights models are the key to a healthy AI ecosystem going forward, then surely the ability to run beefy models well on local systems will be part of that picture. For cost and privacy reasons alone, I think local AI inference will become a keystone workload for personal computers. More importantly, I think PC chipmakers believe that, too. Their internal roadmaps surely already reflect it.

PC system architectures will have to evolve in order to handle the demands of these workloads. For LLM inference in particular, that means we’ll need a balanced mix of data-parallel computing power, copious memory capacity, and ample memory bandwidth.

Even before the AI-hardware crunch really hit, we were in an intriguing moment for PC hardware. Qualcomm entered the market with some compelling new SoCs, and Microsoft’s Prism emulator made running x86 applications on Arm processors truly viable. (I bought a Snapdragon-based laptop for my wife—on purpose!) Rumors about an Nvidia-MediaTek collab circled for ages, and then we finally got the GB10 chip in the DGX Spark. New packaging tech has made “system-on-a-chip” solutions into something more like “system-on-a-package” setups with wild variety between the various offerings. Meanwhile, Apple has emerged as the apparent market leader with its M-series processors initially derived from its iPhone SoCs.

With the M2 and M3 Ultra processors, Apple’s platform team built what are arguably the best consumer chips for running generative-AI workloads like large language models (LLMs). I’m not sure what their targets were when they conceived the M2 Ultra. Local LLMs weren’t yet an obviously important workload, I don’t think. But the current two-week lead times and crazy eBay prices for Mac Studios have surely validated their architectural choices.

Nvidia and AMD have dipped their toes into the AI SoC waters with the GB10 (DGX/RTX Spark) and the Ryzen AI Max chips, but they haven’t yet fully committed. The table below tells the story.

In its M Ultra offerings, Apple built SoCs with roughly RTX 5070-class GPUs. They have similar peak compute flops, somewhat higher memory bandwidth, and—crucially—many times the peak memory capacity: 512 GB unified for an M3 Ultra Mac Studio vs. 12 GB of dedicated VRAM for the GeForce RTX 5070.

Meanwhile, memory bandwidth is the glaringly obvious bottleneck on both the GB10 and the Ryzen AI Max+ solutions. They have less than half the memory bandwidth of the RTX 5070, and that bottleneck tends to show up when systems based on these chips run relatively sizeable LLMs. Although they have the memory capacity to load large models, their token output rates are often uninspiring.

This situation is not likely to persist.

Hence my core argument, which is Dirk Meyer’s thesis from 20 years ago: the future is fusion. AMD has been teasing the benefits of CPU-GPU integration for decades while reserving its most capable large-scale implementations for the Xbox and PlayStation. The rise of generative AI will supply them—and their many competitors—with the courage needed to do the right thing.

PC SoC makers are going to build truly large and capable SoCs for AI, with big GPUs and well-matched unified memory subsystems. When they do, they will ship products that call into question the need for discrete GPUs for a great many folks, not just those seeking AI processing power.

You’re gonna like it

This development will be a very good thing for PC enthusiasts, gamers, content creators, and anybody else invested in serious desktop computing. Finally, we are going to get a powerful, complete PC gaming and content creation setup on a chip—or at least on a package.

The potential benefits of this sort of integration should be apparent to anyone who has watched the personal computer evolve over time. Once upon a time, one had to buy a separate FPU and install it in order to handle floating-point math properly. Memory controllers lived on core-logic chipsets, and getting a second CPU core meant populating another socket on the motherboard. We all benefited mightily as CPU makers integrated those capabilities into the main products—which now have an embarrassing number of CPU cores and many times the performance at a fraction of the cost of past systems.

Graphics card memory capacities have stagnated in recent years as GPU firms ran into cost and power challenges. Gamers have felt the pain on this front and made their frustrations known, seemingly to little effect. But SoCs tuned for AI inference will fix that problem in ways it’s hard to fully digest. Imagine a GTA VII game authored for systems where the GPU can access 128 GB of fast, unified memory. Future Los Santos is gonna look insane.

Big SoCs will be more efficient in various ways, too. Unified memory means reduced data movement. Not having to shuffle bits between system memory and VRAM can save time and energy. CPUs, GPUs, and other accelerators can work collaboratively on workloads as appropriate, assuming the hardware guys work out some potentially thorny issues like cache coherency and shared data formats.

If things go well, I expect future gaming workloads to involve a mix of CPU work, traditional graphics rendering, neural graphics, and generative-AI inference. This mix should be better served by a single, shared pool of high-bandwidth memory.

Another traditional benefit of integration is a reduced physical footprint. I feel weirdly scandalized by today’s high-end video cards being the size of a shoebox. I mean, I love big GPUs, and priorities are priorities, but holy crap. Do they make Ozempic for PCIe cards? Meanwhile, the DGX Spark and Ryzen AI Halo boxes are much more compact than a PC with just a mid-range video card. Not having a separate video card plugged into a PCIe slot with its own GPU, memory, power distribution, and cooling should enable some nicer choices—or, honestly, just better use of the space inside an ATX case.

There are cost benefits to the reduced size and complexity of big-SoC systems, too. That fact seems tough to wrap one’s head around right now, given the twin challenges we face in the AI hardware crunch and the slow death of Moore’s Law. After all, the AI-inference-focused development systems I’ve been talking about are currently selling for around $5K. But I still believe integration and innovation will make big-SoC systems affordable in the long run. We’ll likely have a spectrum of price and performance trade-offs from which to choose across a range of SoC sizes. The key thing is that well-balanced large- and medium-sized options should exist in the future—and should have compelling benefits over traditional PC configs.

So what happens, you may be asking, to discrete GPUs? Am I saying that PC enthusiasts will have to give up the awesome ability to pop in a video card of their choosing to upgrade their systems?

I guess maybe that day will come, but probably not for a very long time. Discrete GPUs will likely persist, at least as ultra-high-end options.

But I can also see this situation another way: at long last, the GPU—or, more broadly, the data-parallel computing portion of the PC—is becoming the heart of the system. Honestly, it kind of has been in gaming PCs for quite some time. It is for data-center systems now, too. Upgrading that part of the system will still be something you want to do, and in this new world, you’ll likely get some improved CPU cores in the process, since it’s all packaged together.

So I guess I’m saying that when the time comes, you probably won’t mind.

Almost 15 years ago, I published my article “Inside the second: a new look at game benchmarking,” in which I proposed using frame-time-based analysis of gaming performance rather than just average FPS. Doing so has caused me all manner of trouble, most of it positive. In the years since, I’ve largely been working in the tech industry and haven’t had the time to comment publicly on new developments—of which there have been a great many.

I’ve recently found myself with some free time, so I thought I’d take a moment to walk through some of the more intriguing developments in the intervening years around frame-time-based benchmarking, animation smoothness, responsiveness, and more. There’s a whole grab-bag of topics to cover here, so indulge me, if you will.

Durable interest and real progress

I’m gratified to see enduring interest in frame-time-based metrics still showing up in GPU reviews and the like. Not everyone reports the same metrics; approaches vary widely, and it has been that way virtually from the beginning. I have always advocated simply for paying attention to frame times—as connected to animation smoothness experienced subjectively by the user—and avoiding the fundamental mistake of averaging out notable differences in performance. Which metrics folks choose to use is up to them (though I do have some opinions).

The software tools to capture frame-time data have improved, led by things like CapFrameX. I’m especially gratified when I see YouTubers and streamers using frame-time overlay tools and connecting their outputs to animation smoothness as they play. There was a (frankly somewhat ridiculous) time when we had to use slow-motion video cameras (which were then somewhat rare) to prove that a frame-time spike corresponded with a blip in game animation. With today’s visual tools and focus, everyone kind of gets it now.

I also have the sense that there’s been progress generally on the frontier of animation smoothness in gaming. Such progress is always kind of halting—shout-out to Unreal Engine 5—but with the right tools and metrics now more or less expected, the industry has been paying attention to, and optimizing for, the right targets. Over time, that fact has paid dividends, as has the fact that at least some of the key hardware bottlenecks have gotten faster (wider?) over time. So I’m going to call this one a provisional win, with the awareness that software bloat has an insatiable ability to absorb everything in its path if it’s not kept in check. (Shout-out to our near-future vibe-coded game engine components.)

Different flavors of 1% lows

One of the more popular frame-time metrics that you’ll see in reviews and such is the so-called 1% low FPS, typically reported alongside the FPS average as a sort of notable minimum number. The only problem with this situation is that, well, there are three entirely different metrics in use, all of which are getting labeled as “1% low” results.

The first of these metrics is just the 99th-percentile frame time number converted into FPS. To get this number, you must:

1. Record a series of frame-to-frame intervals (or frame times) during gameplay.

2. Sort the distribution from lowest to highest values.

3. Identify the frame time where 99% of all values in the distribution are faster; that is your 99th-percentile frame time (sometimes called the P99 value).

4. Divide 1000 milliseconds by that number to convert to frames per second. For example, if the 99th-percentile frame time is 50 milliseconds, 1000 / 50 works out to 20 FPS.

That’s one version of the 1% low. But, as I’ve learned from talking to smart folks like Steve Burke from GamersNexus, not everyone calculates the 1% low that way. Steve—and apparently a number of other folks—calculates it differently. Steps 1-2 are the same as above, but then this happens:

3. Isolate the slowest 1% of frames in the distribution and average them together.

4. Convert this number to FPS.

This difference is consequential. Instead of ruling out the slowest 1% of frames as potential outliers, this metric focuses exclusively on the slowest 1% of frames—the tail of the distribution—and averages them.

The third “1% low” metric focuses on a percentage of the total time represented in the distribution. Let’s work through the steps.

1. Record a series of frame-to-frame intervals during a 10-second gameplay sequence.

2. Sort the frame times from highest to lowest.

3. Beginning with the highest value, add the frame time values together until their cumulative total reaches or exceeds 100 ms—1% of the total test time.

4. Note the frame time that causes the cumulative total to reach or exceed that threshold.

5. Divide 1000 milliseconds by that value to convert to frames per second.

CapFrameX calls the GamersNexus method “1% low average” and this other, time-focused method “1% low integral.”

To get a sense of the practical differences between these metrics, I pointed Codex at one of my old review data directories and asked it to build a spreadsheet showing me the 1%-low and 0.1%-low numbers using all three methods. Here’s how that looks. Marvel at the very old GPU names.

I’ve mentioned my concerns with averages, but perhaps counter-intuitively, I don’t hate the 1% low average metric. You can see it’s a more sensitive metric than the P99 one, producing lower FPS numbers thanks to its focus on the slowest frames. Given that we seem to have made progress with game smoothness optimizations over time, a more sensitive metric might be more appropriate to the current moment.

The 1% low average actually focuses on the tail data rather than just establishing a percentile cutoff point. Averaging the tail can hide very different kinds of slowness—huge, multi-second frame-time spikes could look the same as a more benign, persistent series of somewhat slow frames. But the same could be said for percentile cutoffs, and like them, this method can still flag problems and invite closer inspection.

The x% low integral appears to be an even more sensitive metric, particularly at the 0.1% cutoff point with a data set like this one, where there are substantial slowdowns in the extreme tail of the distribution. Again, the additional sensitivity of this method isn’t necessarily a bad thing. Depends on what you want to get out of it.

The obvious comment to make here is that we need to be disciplined about labeling results clearly and making sure we understand which metric is being used when discussing these things and, especially, when making comparisons.

Intervals vs. latency and input lag

Speaking of terminology, there is one clarification I’d like to put on the record. In my later articles involving frame-time testing, I talked about “frame latencies” and the importance of them. What I meant by “latency,” in that case, was simply the wait for the next frame of animation. I do think the wait for the next frame of animation is important, but talk of latency has since shifted mostly toward discussions of input lag—an adjacent but ultimately distinct topic.

I think it’s more helpful to talk about frame-to-frame intervals—or simply frame times—when discussing the progression and pacing of game animation. We can leave latency for the input lag discussion.

Huge progress on input lag

Speaking of which, another wonderful advance in this domain in recent years is the new focus on reducing input-to-response latency. I’m happy to say I was a part of the team that shipped Radeon Anti-Lag, one of the first software features to reduce unnecessary input lag in games. Nvidia followed shortly afterward with Ultra-Low Latency Mode and later Reflex, which moved latency optimization into the game engine. Crucially, they also supplied the industry with decent tools to measure input lag, a prerequisite to meaningful optimization.

I have to note that our team had plans to release latency testing hardware for the world to use first, but I’ve learned that getting things done inside of big companies can sometimes be quite challenging. Today, though, you can check out the Arduino Latency Meter here.

I suppose it’s worth giving you a few words about input lag reduction vs. animation frame times. The two things are obviously related, since new frames of animation carry the visual responses to one’s inputs.

I spent a fair amount of time testing Radeon Anti-Lag before we shipped it, and I have to say that the largest benefits were not what we marketed. Much of the marketing for any latency reduction feature is almost inevitably going to be focused on e-sports type games, since quick response times are huge in a competitive scenario. (And since e-sports games drive graphics card sales.) But in such a scenario, taking about a frame’s worth of wait time out of the input-to-response loop—which is what our feature did—typically isn’t worth much.

Why? Because the e-sports folks tend to crank down the visual settings to get super-high frame rates. At 240 FPS, a one-frame reduction in wait time only works out to four milliseconds. I’m not sure what the limits of human perception are on this front, but I’d wager we’re getting close to them.

Conversely, if you’re using a laptop with a weak integrated GPU struggling to run a demanding AAA game at 40 FPS, chopping out a frame of wait time can get you a 25-ms reduction in input lag. That, my friends, is frigging revolutionary for the playability of a game on a slow system. Everything feels so much more connected that even a setup averaging 40 FPS seems eminently viable instead of a total waste of time. The input-response loop is a huge component of perceived game fluidity and playability. I tested this very scenario multiple times before and after we shipped our software feature, and I wish we could have told the story of its benefits better.

Happily, the community now has tons of different tools for measuring input lag, and there is at least some effort on the part of GPU makers, display makers, and hopefully game developers to optimize for this target, as well. Even cheap TVs have a game mode, although the benefits are sometimes dubious.

FPS vs. frame times

The discussion above about relative benefits hints at another topic I’d like to address briefly. I’ve become increasingly convinced of the value of quantifying game and animation performance in terms of natural, native units—time—rather than alternatives like frame rates. Let me explain why.

Imagine you’re comparing two GPUs. One averages 30 FPS and another averages 60 FPS in the same game. One might see that result and say “GPU X is 30 FPS faster than GPU Y,” and that statement would be true—in that specific context. But a frame per second is an elastic concept, depending on how fast we’re going. Take another example where GPU X runs a game at 120 FPS, and GPU Y runs it at 150 FPS. That is also a 30 FPS delta—in a rather different context.

In the first example, the delta between the GPUs works out to 16.7 ms per frame—a notable gap. In the second example, though, the 30-FPS delta amounts to 1.7 ms per frame. One of these things is not like the other.

In short, additive FPS differences have no consistent meaning.

That’s because at higher frame rates, inter-frame values grow very small in a hurry. Let’s illustrate this point with a plot of the non-linear relationship between FPS and frame times.

Beware someone selling you a CPU that’s “better for gaming” because it runs your favorite e-sports title at 240 FPS while the competition can “only” hit 210 FPS. That’s a delta of 0.6 ms/frame, which ain’t much. You might want to consider other factors.

My sense is that, when in doubt, the best language to use to describe differences in game performance is just time in milliseconds. It’s clarifying.

Displays are insane now

I’m writing these words using a 32” 4K desktop monitor. It’s an OLED with a 240 Hz refresh rate, variable refresh rate support, and near-instantaneous pixel response times. It has a special gaming mode where it does 1080p at 480 Hz—not to mention that it has perfect blacks, crazy peak brightness in HDR, and a color gamut wider than Alaska.

It makes the sharp folks at Blur Busters behind testufo.com seem delusional, because it passes almost every test without showing any artifacts. (“What, exactly, are these people on about?”)

This, my friends, is completely frigging bonkers.

I hope folks appreciate what’s possible now. And I hope, instead of fretting about current GPU and memory prices, gamers realize the best upgrade they can make may well be a better monitor—for fluidity, responsiveness, visual fidelity, and sheer impact.

Minor frame-time variations are vastly less disruptive on a more forgiving display. The FPS vs. frame time plot above can also function as a refresh rate vs. quantization step plot, since the math is the same. At 240 Hz, like on my current monitor, the quantization step between fixed-rate screen updates is 4.2 ms—one-quarter of the interval on a 60 Hz display. Whenever the GPU has a new frame ready, you’re going to see it quite soon, perceptually speaking.

This plot helps illustrate the relative potential for smoothness.

So yes, this is good.

This new display reality ought to inform how we spec PCs and how we think about minimum requirements for gaming. In my view, one should spec a gaming system with a fast display, and it’s worth giving up a tier or two in terms of the GPU or CPU spec in order to do so.

Is VRR cooked, chat?

One question I have in this context—and I legitimately don’t know the answer—is whether variable refresh rate features like G-Sync and FreeSync still add real value and have a bright future. I’d like to look further into the exact, delivered benefits of the ability to vary update rates compared to something like a 240 Hz OLED running at a fixed refresh rate. (For this comparison, I’m assuming vsync is enabled in the fixed-refresh case, so neither solution tears.) We know those benefits are increasingly marginal as fixed refresh rates rise, given the shrinking quantization steps illustrated above. And I know that some displays, particularly LCD panels, have had real trouble dealing with the combination of varying refresh rates while supporting HDR-class dynamic brightness.

Will the simplicity of a fast, fixed refresh rate win out in the end? Perhaps not for mobile devices where power consumption is king, but everywhere else? I dunno.

Wrapping up

That’s probably about enough for now. I guess I had plenty to say after over a decade without publishing something like this. There are still more topics I’d like to address, and I’ll call my shot on two of them.

First, one of the most difficult lessons I learned from working in the industry is that having the right metrics without the right data isn’t worth much. I was able to influence some of the places where I worked to use frame-time-based metrics in their performance reporting, but typically, they were reporting those metrics against data sets produced by scripted benchmarks, not actual gameplay sequences. The results were therefore of limited value in understanding how our product compared to the competition in real-world use. Turns out big companies are loath to pay people to play video games for testing. Engineers and engineering leaders like automation—even at the cost of actual insights.

I think the rise of AI has created an opportunity for tools to capture something much more like real-world gameplay. I’m curious to see what’s possible in the coming years.

Second, one of the unsolved problems in gaming animation remains the synchronization between the physical simulation in the game world—which dictates the content of each frame of animation—and the time when the frame is displayed to the user. Different game engines vary in how they handle this stuff, but from what I gather, the answer is still generally just “go fast enough, and it will all work out.” Usually it does, more or less, but more precise synchronization might pay surprising dividends. I know work is being done on this front, and I’d like to revisit the subject again soon.

I haven’t even touched on a bunch of other fascinating developments in gaming and graphics, like the huge software improvements in Linux for running Direct3D games, neural upscaling, or frame interpolation. I suppose that means there’s room for more of this sort of thing.

If you’d like to see more, please subscribe to Damage Labs and let me know what you’d enjoy seeing covered. With enough support, I’d like to turn this into a paying gig and continue writing regularly. We’ll see where it goes.