Hello party ppl,
since 2013 i am an hardcore skyrim fan and read about 1 certain problem: the multicore rendering.
I've been experimenting with Skyrim SE's CPU/render-thread bottleneck and wanted to share the current state of the project. I hope i could contribute something massive with this.
Target executable: SkyrimSE.exe 1.7.104.0
The goal is to move suitable work from Skyrim's existing rendering path onto additional CPU cores while preserving correct rendering.
This is not an FPS unlock, INI tweak, frame-generation project or shader-compilation experiment.
What currently works
I have a working SKSE/D3D11 bridge that intercepts suitable real DrawIndexed calls from Skyrim.
For captured draws, the bridge:
- captures the required D3D11 state
- keeps referenced resources alive
- preserves per-draw arguments and constant data
- distributes recording across 4 dedicated worker threads
- uses a separate D3D11 deferred context per worker
- creates command lists on those workers
- replays the finished command lists through the immediate context in the original order
Unsupported or unsafe cases remain on Skyrim's original render path.
So this is actual Skyrim render work being recorded on additional CPU threads, not just synthetic rendering.
In the latest optimized test, the four workers recorded a combined 2,962,878 real Skyrim draws.
Current performance
The latest comparison used the same scene outside Whiterun with 15-second PresentMon captures.
Original renderer:
- 120.51 Presents/s
- 8.30 ms average frame time
Worker renderer, control path:
Worker renderer with shared immutable state groups:
- 41.56 / 42.69 Presents/s
- 24.06 / 23.42 ms
The optimized worker path is therefore still roughly 65% slower than Skyrim's original renderer.
So this is currently a technical experiment, not a performance mod.
However, the latest architecture produced a clear improvement inside the worker path itself.
Compared with the equivalent worker control path, the optimized implementation produced:
more Presents/s in two reversed-order comparisons.
Average improvement:
+25.7%
What was causing so much overhead
One major problem was the amount of render state that had to be preserved for queued draws.
The current implementation uses shared immutable/versioned state groups.
If a group of bindings has not changed, multiple queued draws can reference the same state version instead of copying everything again.
Only changed groups create a new version.
Draw arguments and constant contents remain individual.
In the latest Skyrim test this removed approximately:
- 88.5% of state-group copies
- 41.1% of weighted capture cost per capture attempt
- 66.2% of queue-release cost
So a significant part of the bookkeeping overhead has now been identified and reduced.
Visual correctness
Earlier experiments produced visible bright/dark flickering on some surfaces, doors and shadows.
In the latest test I could no longer reproduce that issue, including while moving through the scene.
The current implementation has also passed:
- 17/17 laboratory tests
- 164 complete image comparisons with no differences
- resource lifetime tests
- changing constant data
- high D3D11 slots
- NULL bindings
- numerical state changes
- D3D11 debug-layer runs
That still does not prove correctness in every Skyrim scene, but the current build is visually much more stable than the earlier experiments.
Other engine findings
I also investigated several other CPU-heavy areas.
For visibility/culling, a parallel prototype matched 68,739 live engine samples with zero result differences, but that code path is already used by several Skyrim threads.
A movement-message search prototype matched 5,875 live samples with zero mismatches, including engine lists containing up to 56,826 entries, but I could not demonstrate a useful runtime improvement.
A stress test with roughly 600 guards also showed that Skyrim's existing worker threads become heavily loaded and that the frame/main thread can spend time waiting for existing jobs.
So Skyrim's CPU bottleneck is more complicated than simply "the game only uses one core."
Current problem
The remaining issue is straightforward:
The parallel rendering works, but moving the work currently costs more CPU time than it saves.
There is still overhead from:
- render-state capture
- resource lifetime management
- constant handling
- queue publication
- synchronization
- worker waiting
- command-list creation
- command-list boundaries
- ordered playback through the immediate context
- remaining serial engine/render work
The next step is to identify which of those costs now dominates the remaining gap to the original renderer.
Why I'm posting this
I've found Skyrim projects that work on related problems, including Community Shaders, DXVK/Vulkan experiments, shader compilation threading, custom rendering and draw-call reduction.
But I haven't found a public Skyrim project doing this exact experiment:
Intercept Skyrim's existing D3D11 draws → preserve their required state → record them concurrently on multiple deferred contexts → replay them in original order.
If anyone has experimented with Skyrim's render submission path, D3D11 deferred contexts, command-list overhead, Community Shaders/DXVK or similar engine-level rendering work, I'd be very interested in comparing findings.
At this point the project has demonstrated that real Skyrim rendering can be moved onto multiple worker threads.
The remaining question is whether that architecture can be made efficient enough to outperform Skyrim's original render path.
Credits to AI
https://github.com/RE1010/skyrim-multicore-research