What Your CPU and GPU Are Actually Doing While Running iRacing: A Technical Deep Dive

With AMD’s Ryzen 9000X3D series and Intel’s Core Ultra 200S now in the wild – and iRacing’s new Spark graphics engine moving from prototype into full production through 2026 – this is a full refresh covering both the CPU and GPU sides of what’s happening inside your sim rig. The 9800X3D is still an absolute weapon for sim racing on the current DirectX 11 engine, but the rendering side is about to change in a meaningful way. Worth understanding both halves of the picture before you commit to a 2026 build.

---

Right, let’s have a chat about what’s really going on under the bonnet whilst you’re trying to keep it between the white lines at Monza. I’ve spent the last month diving deep into CPU monitoring tools, staring at thread utilisation graphs, and generally being that annoying bloke who brings up processor architecture at the pub. But here’s the thing – understanding how iRacing uses your CPU isn’t just tech nerd territory. It’s the difference between smooth, consistent performance and wondering why your £2,000 rig stutters when someone joins the session.

Unlike your typical modern game that spreads its workload across cores like Nutella on toast, iRacing has a rather unique (some might say old-fashioned) approach to CPU utilisation. And before you ask – yes, this matters if you’re running VR, triples, or a single monitor setup.

---

The 60Hz Heartbeat: Understanding iRacing’s Core Loop

At the heart of iRacing lies a fundamental truth: the physics engine must run at exactly 60Hz. No more, no less. This means your CPU has precisely 16.7 milliseconds to complete each physics calculation cycle. Miss that deadline, and you’ll see the dreaded yellow or red bar in your meter box (press F to bring it up).

Here’s what’s happening in those critical milliseconds:

The Physics Thread: Where the Magic Happens

The physics thread is iRacing’s main performance bottleneck, and it’s largely single-threaded. During each 16.7ms window, your CPU is calculating:

Per-Car Physics (The Heavy Lifting)

• Tyre Model Calculations: Each of the four tyres uses complex Pacejka-based models, calculating grip levels, slip angles, heat generation, wear patterns, and deformation. This alone can consume 30-40% of the physics budget per car.
• Suspension Dynamics: Springs, dampers, anti-roll bars, and geometry calculations for all four corners. The CPU tracks every millimetre of suspension travel and how it affects the car’s behaviour.
• Aerodynamic Modelling: Real-time calculations of downforce, drag, and how these change with car attitude, ride height, and proximity to other vehicles (dirty air simulation).
• Collision Detection: Precise calculations for car-to-car and car-to-environment impacts, including damage modelling.

Track Surface Interaction

• Surface mesh calculations for bumps, kerbs, and track irregularities
• Dynamic track temperature and rubber buildup
• Weather effects on grip levels
• Marbles and debris simulation

The Multiplayer Overhead

Here’s where iRacing differs from your typical racing game. In a 40-car race, your CPU isn’t just calculating physics for your car – it’s processing position updates and physics states for every other car on track. This is why grid size has such a massive impact on CPU load.

The networking overhead includes:

• Interpolation and extrapolation of other cars’ positions
• Latency compensation calculations
• State synchronisation across all clients
• Anti-cheat verification

CPU Core Usage: Why Single-Thread Performance Still Reigns

I’ve monitored CPU usage across dozens of races, and here’s the reality: iRacing primarily hammers 2-3 cores, with the physics thread typically pinned to a single core at near 100% utilisation. Additional cores handle:

• Core 1: Main physics thread (usually 90-100% usage)
• Core 2: Renderer preparation and draw calls (60-80% usage)
• Core 3: Audio processing and network handling (40-60% usage)
• Cores 4+: Texture streaming, UI updates, background tasks (10-30% usage)

This is why a 6-core CPU with exceptional single-thread performance will outperform a 16-core processor with lower per-core speeds in iRacing.

The Renderer Thread: GPU Communication

While the physics thread does the heavy lifting, the renderer thread acts as the middleman between your CPU and GPU. It’s responsible for:

• Preparing draw calls for the GPU
• Frustum culling (determining what’s visible)
• LOD (Level of Detail) calculations
• Shadow map generation
• Mirror and reflection calculations (particularly CPU-intensive)

The renderer thread typically runs 1-2 frames behind the physics thread, which is why you might see physics running smoothly (green C bar) while still experiencing visual stutters.

What Your GPU Is Doing Each Frame

Now flip to the other side of the rig. The CPU’s just finished a physics tick and handed your renderer thread a list of “draw this car here, this kerb here, this sky dome here”. The GPU’s job is to turn that list into pixels – and the workload is genuinely different from anything happening on the CPU side.

For a single 1440p frame on triples (so 7,680×1,440 effective resolution) at modern settings, your GPU is doing roughly this:

• Vertex transforms. Every vertex on every visible car, every track surface polygon, every barrier and grandstand gets transformed from 3D world space into your screen’s 2D coordinate system. Modern tracks at iRacing’s detail level run into the millions of vertices. The GPU’s geometry pipeline grinds through these in parallel – this is what hardware T&L was invented for.
• Rasterisation and pixel shading. For each visible triangle the GPU works out which pixels it covers, then runs a pixel shader on each one – texture sampling, lighting calculations, normal mapping, environmental reflections. With multisampling (MSAA 2x or 4x) the shader runs multiple times per pixel for the edge samples. This is where most of your GPU’s compute units spend their time.
• Shadow maps. iRacing renders shadow buffers for the sun and major light sources at the start of each frame. Higher shadow detail means rendering the entire scene multiple times into off-screen buffers. Crank shadow detail up and you’re effectively asking the GPU to render the scene 2-3 times per visible frame.
• Reflections. Mirror reflections, paint reflections, helmet visor reflections – each one is another partial render of the scene from a different camera angle. Mirror detail is one of the biggest single GPU costs in iRacing because each mirror is a separate render pass.
• Post-processing. Tone mapping, motion blur (if you’ve enabled it), bloom, depth of field, anti-aliasing resolve. These run as full-screen passes after the main scene is done, sampling the framebuffer to produce the final image you see.
• Output and display sync. The finished framebuffer gets handed to the display pipeline – and this is where VR adds its complications, since the headset needs the frame split for both eyes and reprojected if you’ve missed the deadline.

The thing that catches people out: the GPU is fundamentally a parallel beast. A modern GPU has thousands of compute units that can all work on different pixels at the same time. So adding visual detail (more cars, more shadows, denser textures) scales reasonably well as long as you’ve got the compute budget. What doesn’t scale well on a GPU is anything that breaks the parallel pipeline – things like state changes between draw calls, switching textures, or asking the GPU to wait for the CPU to send the next command. And that’s where the DirectX version starts to matter.

The DirectX 11 Bottleneck – Why iRacing’s Renderer Is Showing Its Age

iRacing currently runs on a custom in-house engine built against DirectX 11. You can confirm this yourself: the renderer config file in your iRacing folder is literally called rendererDX11.ini. DirectX 11 was released in 2009. It’s been a perfectly capable graphics API for a long time – but it has one specific limitation that’s increasingly painful for sim racing as monitors and GPUs have moved on.

That limitation is how DX11 handles draw calls. Every separate object on screen – every car, every kerb section, every signboard – needs the CPU to issue a “draw call” to the GPU telling it what to render and how. Under DX11, command list submission is fundamentally single-threaded. Even if you’ve got a 16-core CPU, only one of those cores can be feeding draw calls to the GPU at any given moment. The other 15 sit there with nothing useful to do for the rendering side of the workload.

For most games this isn’t a problem because they don’t have many draw calls. For iRacing, three things make it a much bigger problem:

• Triple monitors triple the draw call work. You’re rendering the same scene from three slightly different camera angles, each with its own complete pass of draw calls. The single submission core has to push three times as many commands per refresh.
• VR doubles it again. Each eye is its own render. A triple-monitor VR rig – admittedly rare – would have the single core trying to feed six render passes worth of draw calls per frame.
• Mirrors and reflections each add a partial pass. If you’re running with detailed mirrors and helmet reflections on, that’s another set of draw calls per frame.

This is why iRacing on a triple-screen setup with a flagship GPU often shows the GPU sitting at 50-60% utilisation while one CPU core hits 100% – the GPU’s literally waiting for commands the CPU can’t issue fast enough. Adding more cores doesn’t help. Buying a faster GPU only helps up to the draw-call ceiling, then stops scaling. The bottleneck is the API, not the hardware.

I ran the numbers on my own setup last month – RTX 3080 on triple 1440p, full GT3 grid at Spa. GPU sat around 55% during the race start where the draw-call load is heaviest. Switch to a 5-car field and the same GPU jumped to 80%+ utilisation because the draw-call submission cost dropped enough to let the GPU do the work it’s capable of. That’s the DX11 bottleneck in one number.

The Spark Engine and DirectX 12 – What Changes Through 2026

iRacing have been working on a new engine for several years. It’s called Spark, and as of the February 2026 development update they’ve moved it from prototype into full production. This is the most consequential thing happening to iRacing’s technical foundation since the game launched – and it directly addresses everything I’ve just described.

What Spark changes:

• DirectX 12 instead of DirectX 11. The headline change. DX12 lets multiple CPU cores submit draw commands to the GPU in parallel – so instead of one core feeding the GPU and 15 sitting idle, the work spreads across however many cores you’ve got. For triples and VR specifically, this is the change that lifts the draw-call ceiling.
• Lower per-call CPU overhead. DX12 also has a leaner driver model than DX11. Each individual draw call costs the CPU less, on top of the multithreading benefit. Which means more of your CPU budget can go to physics and AI work rather than ferrying commands.
• Async compute. DX12 can have the GPU doing compute work (like physics post-processing or audio mixing) at the same time as graphics work. For iRacing specifically this opens up better use of the unused GPU compute capacity that DX11 leaves on the table.
• Foundation for ray tracing later. Not part of the initial Spark release, but DX12 Ultimate is what you’d build raytraced reflections and global illumination on top of. The architectural choice now leaves that door open without another rewrite.
• Better night lighting. Specifically called out as a focus area in the February 2026 update – iRacing’s existing night lighting is one of the engine’s weakest visual moments, and Spark’s lighting model is being designed from scratch to fix that.

The timeline. iRacing’s been deliberately conservative about specific dates. The vertical slice (a small slice of the full game running on the new engine, used to validate everything’s working end-to-end) was targeted for the end of Season 1 2026. The full engine is expected to take all of 2026 to deliver. So you’re looking at a phased rollout through this year, with the first user-facing benefits probably appearing in Season 3 or Season 4 of 2026, and full migration likely closer to the end of the year.

For people building rigs now, this matters in two ways. First, your current 9800X3D / 9950X3D pick is the right call regardless – DX12 will use those cores better, but the X3D cache advantage isn’t going anywhere. Second, GPU choices that look overpriced for current iRacing (RTX 5080 / 5090 / RX 9070 XT) will start to look more reasonable once Spark ships, because the GPU side will finally be able to absorb everything you can throw at it. Don’t downgrade your build for the current API – buy for what’ll be here within 12 months.

For racers running today: the practical upshot is that throwing more cores at iRacing in 2026 doesn’t help much, but it will help a lot once Spark lands. The 9800X3D’s eight-core single-CCD design hits the current sweet spot precisely because the existing engine doesn’t reward more cores. After Spark ships, the 9950X3D’s twelve cores will start showing their advantage in heavy AI fields and VR.

---

AI Opponents: The CPU Killer

Running AI races? Each AI driver requires their own “brain” running on your CPU. The calculations include:

• Racing line computation
• Overtaking decisions
• Defensive driving logic
• Tyre and fuel management
• Mistake generation (yes, they’re programmed to occasionally mess up)

In my testing, each AI car adds roughly 2-3% CPU overhead on modern processors. A full field of 40 AI cars can bring even high-end CPUs to their knees.

VR: The Double-Edged Sword

VR adds another layer of complexity. Your CPU must:

• Render two viewports (one per eye)
• Handle additional tracking calculations
• Manage foveated rendering (if supported)
• Process higher frame rates (90Hz or 120Hz typical)

Interestingly, VR can sometimes reduce CPU load by limiting visible cars and track detail, but the higher frame rate requirements usually result in a net increase in CPU demand.

Real-World Performance: Current CPU Picture

---

Single Monitor Performance (1440p)

---

VR Performance (Quest 3 @ 120Hz)

The Current Champions

AMD Ryzen 7 9800X3D – The New King

• Single-thread performance that finally matches Intel
• Massive 104MB cache (L2+L3) that iRacing loves
• Consistent frame times even with 40+ car grids
• Typical performance: 140-180 FPS (triples, high settings)
• Price: £410-450 / $450-480
• View on Amazon

Recommended AM5 Motherboard: MSI MAG X670E Tomahawk WiFi – Excellent VRM cooling and PCIe 5.0 support for around £250/$280.

AMD Ryzen 7 7800X3D – Best Value Champion

• Previous generation, but still exceptional for iRacing
• 96MB cache helps maintain steady frame times
• Nearly matches 9800X3D in iRacing specifically
• Typical performance: 130-170 FPS (triples, high settings)
• Price: £310-340 / $340-380
• View on Amazon

Budget AM5 Board: ASUS TUF Gaming B650-Plus WiFi – Solid performance without breaking the bank at £180/$200.

Intel Core i9-14900K – The Multi-Tasking Option

• Excellent single-thread performance (6.0GHz boost)
• 24 cores great for streaming/recording while racing
• Higher power consumption and cooling requirements
• Typical performance: 135-175 FPS (triples, high settings)
• Price: £380-420 / $420-460
• View on Amazon

Recommended LGA1700 Board: ASUS ROG Strix Z790-E Gaming WiFi – Solid power delivery for the hungry 14900K, around £400/$450.

Budget Conscious Options

AMD Ryzen 7 9700X

• Zen 5 architecture without 3D V-Cache
• Still excellent for iRacing at a lower price point
• 5.5GHz boost, 40MB total cache
• Price: £280-305 / $305-330
• View on Amazon

Optimising Your CPU for iRacing

BIOS Settings That Matter

1. Disable CPU Power Saving Features
   • Disable C-States
   • Disable Cool’n’Quiet (AMD) or SpeedStep (Intel)
   • Set Windows Power Plan to High Performance
2. Memory Configuration
   • Enable XMP/EXPO profiles
   • Aim for DDR5-6000 with tight timings for Ryzen 9000
   • Intel can often run DDR5-7200+ stable
3. Core Isolation
   • Use Process Lasso to pin iRacing to specific cores
   • Isolate the physics thread to your fastest core
   • Keep background processes on efficiency cores (Intel) or lower-numbered cores

Windows Optimisations

1. Disable GPU Hardware Scheduling – Can introduce latency
2. Set iRacing CPU Priority to High (not Realtime – that can cause issues)
3. Disable Windows Game Mode – Often causes more harm than good
4. Close RGB software – Seriously, it’s a surprising CPU hog

Common CPU Bottlenecks and Solutions

“My CPU is at 50% but I’m dropping frames!”

Remember, iRacing can’t use all your cores effectively. If Core 0 is maxed out while others idle, you’re CPU-limited regardless of overall usage.

“VR performance tanks with 20+ cars”

This is normal. Solutions:

• Reduce visible car count in graphics settings
• Lower mirror detail
• Disable cube maps
• Consider fixed foveated rendering if available

“AI races destroy my performance”

AI is incredibly CPU-intensive. Options:

• Limit AI field to 20-25 cars maximum
• Reduce AI difficulty (simpler calculations)
• Avoid AI races at complex tracks (Nordschleife, Long Beach)

Future-Proofing: What’s Coming

iRacing’s developers have hinted at better multi-threading for the physics engine, but it’s a massive undertaking. The current engine architecture dates back to NASCAR Racing 2003, with continuous evolution rather than complete rewrites.

Upcoming developments that might affect CPU usage:

• Rain physics improvements (more CPU load)
• Dynamic track conditions (potential for optimisation)
• New tyre model iterations (historically increases CPU demand)
• Potential DX12 renderer (could reduce CPU overhead)

My Testing Methodology

All performance figures in this article come from:

• 30-car GT3 races at Spa-Francorchamps
• Triple 1440p monitors (7680×1440 total resolution)
• High settings with 2x MSAA
• Replay mode for consistency
• Minimum 1% frame times recorded

The Bottom Line: CPU Recommendations for 2025

For Maximum Performance (Money No Object):

• AMD Ryzen 7 9800X3D – Simply the best for iRacing
• 32GB DDR5-6000 CL30
• Expect 150+ FPS consistently

Best Value Performance:

• AMD Ryzen 7 7800X3D – 90% of the performance, 75% of the price
• 32GB DDR5-6000
• Budget for good cooling

Budget Build:

• AMD Ryzen 5 7600X or Intel i5-13600K
• 16GB DDR5-5600
• Will handle iRacing well at 1080p/1440p

For Streamers/Content Creators:

• Intel Core i9-14900K – Extra cores for encoding
• Consider AMD Ryzen 9 9950X if you need maximum multi-thread
• 32GB minimum, 64GB recommended

Complete Gaming PCs from Our Partners

If you’re looking for a complete system rather than building your own, our SimRacing partners have some exceptional pre-built options:

Summary: It’s All About That Physics Thread

iRacing’s CPU usage patterns reflect its uncompromising approach to simulation accuracy. While modern games distribute their workload like a well-organised pit crew, iRacing puts most of the burden on a single crew chief – that main physics thread.

Understanding this helps explain why a 6-core CPU with exceptional single-thread performance will give you a better iRacing experience than a 32-core workstation processor. It’s not about how many cores you have; it’s about how fast your fastest core can complete those physics calculations every 16.7 milliseconds.

The good news? Modern CPUs are finally fast enough that even mid-range options can deliver a great iRacing experience. The key is choosing the right processor for your specific needs and optimising it properly.

Happy racing, and may your C bar stay forever green.

---

Performance figures based on testing in January 2025. Your results may vary based on system configuration, track complexity, and car count. All prices are approximate and subject to change.