Same Game, DX11 vs DX12 vs Vulkan? Modern Graphics API Architecture, CPU Overhead & Per-Game Comparison.

2026-10-26 ｜ GPU Repair ｜ 22 min read ｜ HK GPU Fix Editorial

重點摘要

When one game offers DirectX 11, DirectX 12, and Vulkan, the fastest choice is not universal. Each API changes how the CPU submits work, how shaders compile, and how drivers manage state. This guide explains those architectures and gives a controlled same-scene comparison method for choosing per game.

Why the Same Game Can Feel Different Under Each API

A modern game that lists several graphics APIs in its settings menu is not offering three versions of the same renderer. It is offering three different contracts between the game engine, the graphics driver, and the hardware. The visible scene, the art assets, and the intended gameplay may be identical, but the path that turns a frame description into pixels on screen changes in ways that affect CPU load, frame-time consistency, loading behaviour, and sensitivity to driver and system updates.

That is why advice of the form "always use DirectX 12" or "Vulkan is always faster" fails in practice. On a system where the processor is the bottleneck, an API that spreads submission work across threads can smooth frame delivery. On a system where the graphics processor is the bottleneck, the same API may make little visible difference, because the time spent shading pixels dominates. On a newly released title, an API path that has received less driver tuning may show hitching that disappears after a patch, while the older path remains stable. The correct question is therefore not which API is best in the abstract, but which API behaves best for this game, on this hardware, with this driver, under a repeatable test.

This guide answers that question from first principles. It explains what each API asks the CPU to do, how shader and pipeline compilation differs, where CPU overhead actually comes from, and how to compare APIs fairly by changing one variable at a time. It does not rank APIs by invented scores, and it does not claim a result for any particular title, because a result measured on one combination of hardware, driver, and game version does not transfer to another.

What a Graphics API Actually Does

A graphics API is a language and a set of rules for describing work to the graphics processor. Every frame, the game engine must tell the GPU what to draw, in what order, with which shaders, textures, buffers, and render states, and how the result should be presented to the display. The API defines how those instructions are packaged, validated, and handed to the driver, and how much of that work the driver is allowed to do on the game's behalf.

Three responsibilities matter most for understanding performance differences. First, submission: how draw calls and state changes are recorded and sent to the GPU. Second, state management: how the engine and driver track which shader, texture, blend mode, depth mode, and render target are currently active, and what happens when any of them changes. Third, resource and synchronisation management: how memory, buffers, and textures are allocated, how the CPU knows when the GPU has finished with a resource, and how pipeline objects that combine shaders and fixed-function state are created and reused.

Older APIs took on more of the second and third responsibilities inside the driver. Newer, lower-level APIs move more of that responsibility to the engine. That shift is the central trade-off of this whole topic. When the driver does more, the engine author's job is easier and behaviour is more forgiving, but the driver must perform validation, state tracking, and error handling on a single thread at submission time, which can become a CPU bottleneck. When the engine does more, it can record work in parallel and avoid redundant driver work, but it must get state, synchronisation, and lifetime management exactly right, and mistakes show up as stutter, incorrect rendering, or crashes rather than as a polite error message.

DirectX 11: The Driver-Managed Model

DirectX 11 follows a model in which the driver plays a large coordinating role. The application uses an immediate context to submit work, and the driver validates state, manages resource transitions, and handles much of the bookkeeping that keeps the GPU fed. Deferred contexts exist, but in practice most DirectX 11 engines submit the bulk of their work through a single thread, and the driver serialises and checks that work as it arrives.

The practical consequences are well understood. For engines built around this model, DirectX 11 is predictable and forgiving. State changes are comparatively cheap to express, because the driver absorbs the complexity of translating them into hardware commands. Shader compilation follows a familiar pattern in which shaders are compiled and bound as needed, and the driver can manage caches and fallbacks behind the scenes. This is one reason DirectX 11 paths in multi-API games often feel stable at launch: the path has had years of driver attention, and the engine code that uses it is usually mature.

The cost appears when a scene asks for very many draw calls, frequent state changes, or complex per-object material variation. Each draw call still passes through driver validation and translation, and that work concentrates on the submission thread. When the CPU cannot prepare and submit frames fast enough to keep the GPU busy, frame times rise even though the GPU itself has spare capacity. This is the classic CPU-bound pattern: lowering resolution or graphics quality does not restore smoothness, because the bottleneck is not pixel shading but the rate at which work can be described and handed over. Raising the CPU's single-thread performance, reducing draw-call-heavy settings such as object density or shadow-casting object counts where the game exposes them, or switching to an API that parallelises submission, are the levers that address this pattern. Simply demanding more GPU power does not.

DirectX 11 also has a simpler story for compatibility with older hardware and older rendering techniques. A companion discussion of legacy API compatibility covers the case of much older titles and hardware, which is a different problem from choosing between modern APIs in a current game and is not repeated here.

DirectX 12: Explicit Control and Parallel Submission

DirectX 12 inverts the DirectX 11 bargain. The engine, rather than the driver, owns command list recording, pipeline state objects, resource barriers, and much of the synchronisation logic. Command lists can be recorded on multiple CPU threads in parallel and then submitted together, which directly attacks the single-thread submission bottleneck that limits DirectX 11 in draw-call-heavy scenes.

The key object to understand is the pipeline state object. In DirectX 12, a pipeline state object bundles a set of shaders together with the fixed-function state that affects how they run: input layout, rasteriser state, blend state, depth and stencil state, render target formats, and related settings. Changing any element of that bundle means using a different pipeline state object. This bundling lets the driver pre-validate and pre-translate a complete configuration once, rather than re-validating individual state changes at draw time. It also means that the first time a particular combination is needed, the engine must create that object, and creation can be expensive. If creation happens during gameplay, in the middle of a frame, the result can be a hitch. If it happens during loading, during a shader pre-compilation step, or is served from a cache built on a previous run, the same frame runs smoothly.

Resource barriers are the second concept that explains much DirectX 12 behaviour. The engine must explicitly declare when a resource changes use, for example from being written as a render target to being read as a texture. The driver no longer guesses or inserts these transitions automatically in the same way. Correct barriers are essential for correctness and for performance, because missing or excessive barriers affect how the GPU schedules work and how memory is handled. This explicitness is powerful in experienced hands and unforgiving when an engine path is immature, which is one reason a DirectX 12 path can feel rough at launch and improve markedly after engine and driver updates refine barrier placement and pipeline creation.

Memory management follows the same philosophy. DirectX 12 gives the engine finer control over heaps and allocations, which allows efficient reuse and reduced overhead for engines designed to exploit it. It also removes safety nets. An engine that manages lifetimes correctly gains headroom; an engine that does not can show instability that a DirectX 11 path would have masked.

Vulkan: Explicit Control Across Platforms

Vulkan shares DirectX 12's philosophy of explicit, low-overhead control, but it is designed as a cross-platform API rather than a Windows-only one. It also uses command buffers that can be recorded in parallel, pipeline objects that bundle shader and fixed-function state, explicit synchronisation through barriers and semaphores, and explicit memory management. For a reader comparing APIs in a single Windows game, the practical differences between DirectX 12 and Vulkan are therefore often smaller than the difference between either of them and DirectX 11, and they depend heavily on how much effort the engine team and the driver team have put into each path.

Two distinctions are still worth understanding. First, Vulkan's shader representation and pipeline cache model differ in detail from DirectX 12's. Vulkan pipelines are created from shader modules, and engines commonly build a pipeline cache that persists across runs so that pipelines created in one session can be reused in the next. How completely an engine pre-warms that cache, and whether a driver update invalidates it, affects how much first-run or post-update hitching a player sees. Second, Vulkan's portability means the same engine code can target Windows, Linux, and other platforms with less rewriting, which can affect where development and testing effort goes. A Vulkan path that is the primary path on another platform may receive different attention from a DirectX 12 path that exists only on Windows, or vice versa. Neither fact predicts which path is faster on a given Windows system; both explain why the answer varies by title.

Vulkan also exposes extensions and optional features in a granular way, so two Vulkan implementations can differ in which capabilities they advertise. An engine that adapts gracefully to missing optional features behaves consistently; an engine that assumes a feature is present can behave differently across driver versions. This is another reason to test the actual installed driver rather than trusting a general reputation.

Where CPU Overhead Actually Comes From

CPU overhead is often invoked loosely, so it helps to break it into its parts. Submission overhead is the cost of recording draw calls, binding resources, and handing command lists or buffers to the driver. Validation overhead is the cost of checking that the submitted state is legal and complete. State-change overhead is the cost of switching shaders, textures, buffers, and render states between draws, especially when switches are frequent and poorly sorted. Synchronisation overhead is the cost of waiting for the GPU, inserting barriers, and managing resource lifetimes. Driver-thread overhead is the cost of the driver's own background work, including shader compilation, pipeline creation, and memory management, when that work competes with the game's threads.

In a DirectX 11 path, validation and state tracking concentrate in the driver at submission time. In DirectX 12 and Vulkan paths, much of that work moves into the engine's command recording and pipeline creation, where it can be parallelised but cannot be skipped. This is why a low-level API does not automatically reduce total CPU work. It redistributes work and removes some redundant driver work, and it lets the engine sort, batch, and reuse work more effectively. An engine that batches draws by material, reuses pipeline objects, and records command lists across threads will benefit. An engine that submits draws in a scattered order, creates pipelines on demand during gameplay, and inserts barriers conservatively may not, and may even cost more CPU time than its DirectX 11 counterpart for the same scene.

Draw-call count is the most useful single lens, but it is not the whole story. A scene with many small draws, each with its own material and texture set, stresses submission and state-change paths far more than a scene with fewer, larger draws covering the same pixels. Shadow rendering, reflection passes, and multi-pass effects multiply the number of times geometry is submitted, which is why a setting that looks minor in a menu can have a disproportionate CPU effect. Understanding this helps explain why changing API can matter more in a crowded, object-rich scene than in a simple corridor, and why a comparison made in a menu or an empty area tells little about behaviour in a demanding scene.

Shader Compilation, Pipeline Creation, and Stutter

No discussion of modern APIs is complete without shader compilation, because it is the most common cause of the complaint that a game "runs well except for hitches." Shaders are small programs that run on the GPU for vertex processing, pixel shading, compute work, and other stages. Before a shader can run, it must be compiled or translated into a form the GPU and driver understand, and before a draw can use a particular combination of shaders and state, the corresponding pipeline object must exist.

Engines handle this in several ways. Some compile shaders during installation or first launch. Some compile during loading screens, sometimes with a progress indicator. Some compile on demand the first time an effect appears, which can cause a visible hitch at exactly the moment a new effect, enemy type, or environment feature enters the scene. Some cache compiled results on disk so that subsequent runs avoid repeating the work, until a driver update, a game update, or a settings change invalidates the cache and forces recompilation. DirectX 12 and Vulkan make pipeline creation more visible to the player because the pipeline object is a larger, more explicit unit, but the underlying problem exists in every API. A detailed companion discussion of first-run shader stutter explains that mechanism on its own and is not repeated here; the point for API choice is that a path with more complete pre-compilation or a warmer cache can feel smoother even if its steady-state frame rate is identical to another path.

When comparing APIs, therefore, it is essential to distinguish steady-state performance from warm-up behaviour. A fair comparison warms up each API path separately, in the same scene, before recording results, unless the question being asked is specifically about first-run behaviour. Otherwise the comparison measures which cache happened to be warm, not which API submits work more efficiently. Equally, a comparison made immediately after a driver update measures recompilation as much as it measures API architecture, and should be repeated once caches have rebuilt.

Memory, Resources, and Why Driver Updates Matter

Graphics memory management affects API behaviour in less visible ways. Textures, buffers, and render targets must be resident and accessible when the GPU needs them, and the engine and driver must agree on when a resource can be reused or freed. Low-level APIs give the engine more say in allocation strategy, which can reduce fragmentation and overhead for engines that manage large, stable resource sets well. They also make the engine responsible for declaring transitions and lifetimes, so a path that mishandles either can show flickering, missing textures, or crashes that a more driver-managed path would avoid.

Driver updates interact with all of this. A driver update can change shader compilation, pipeline handling, memory management, and the tuning of a particular API path. It can also invalidate cached pipelines, forcing a fresh round of compilation. This is why an API choice that was correct three months ago can become wrong after a major driver or game update, and why a disciplined approach re-checks the choice after updates rather than treating it as permanent. A companion discussion of update-regression comparison gives a method for isolating whether a change came from the game, the driver, or the settings, and that method applies directly here: change one thing, re-test the same scene, and record what changed.

Frame generation and related frame-rate amplification techniques add another layer that is deliberately kept separate here. Whether a game offers frame generation, and how that interacts with latency and smoothness, is a different question from which base API submits frames most efficiently, and a companion discussion of frame-generation latency covers it in depth. For API comparison, frame generation should be held constant or disabled, so that it does not mask the API difference being measured.

A Controlled Same-Scene Comparison Method

A trustworthy API comparison has a simple discipline: same scene, same settings, one variable. The variable is the API. Everything else stays fixed for the duration of the comparison, including resolution, graphics preset, upscaling setting, frame-rate limit, display refresh rate, and background applications. Changing two settings at once, such as switching API and raising quality, makes the result uninterpretable, because either change could explain any difference.

Start by choosing a representative scene, not the easiest one. A good scene includes the kind of content that stresses the system in normal play: a populated area, a view with varied geometry and materials, or a repeatable route through a demanding environment. Avoid menus, loading screens, and empty areas, which do not exercise submission or shading in a representative way. If the game offers a built-in benchmark, use it only as a supplement, because a scripted camera path may not match interactive play, and because some benchmarks warm caches differently from gameplay. A repeatable in-game route, walked or driven the same way each time, is often more informative than a benchmark that the player will never experience.

Warm up each API path before measuring it. Launch the game under one API, load the scene, spend enough time in it for shaders and pipelines needed by that scene to be created, and then restart the measurement run. Repeat the same warm-up after switching API, because caches and pipeline objects are generally per-API. Record several runs per API rather than a single run, because background system activity, thermal behaviour, and cache state introduce variation. If results vary widely between runs under the same API, that variation itself is information: it suggests the system is sensitive to background load, thermal limits, or incomplete warm-up, and the comparison should not be trusted until that variation is understood and reduced.

Record frame time, not only average frame rate. Average frame rate hides the hitches that players actually feel. Frame-time data, especially the shape of the distribution and the worst frames during the test route, reveals whether an API is smoother even when averages look similar. Note also CPU and GPU utilisation during the route, in broad terms: if the GPU is consistently busy while the CPU has headroom, the scene is GPU-bound and API choice is unlikely to transform the result; if the CPU is saturated on one or a few threads while the GPU waits, the scene is CPU-bound and API choice is more likely to matter. Keep notes in plain language: which API, which driver version, which game version, which scene, which settings, and what was observed. Without those notes, a result recorded today cannot be interpreted after the next update.

Finally, test at the settings actually used for play. An API that wins at low resolution on a CPU-bound test may not win at high resolution with heavy shading, and vice versa. If play normally happens at a particular resolution and preset, that is the configuration to compare. Testing at an artificial configuration and extrapolating to real play is a common source of confident but wrong recommendations.

Common Misconceptions, Corrected

The first misconception is that a newer API is automatically faster. Newer APIs remove a bottleneck; they do not remove the work of shading pixels, and they do not fix an engine path that creates pipelines inefficiently or submits draws in a scattered order. A mature DirectX 11 path can outperform an immature DirectX 12 or Vulkan path in the same game, especially shortly after launch.

The second misconception is that API choice fixes stutter in general. Stutter has many causes: shader and pipeline compilation, asset streaming, background system activity, storage latency, thermal throttling, and unstable frame pacing. Changing API addresses the submission and pipeline portion of that list. If stutter comes from asset streaming or storage, API choice will not fix it, and chasing API settings will waste time that should go to the actual cause.

The third misconception is that the API with the highest peak frame rate is the best choice. A path that averages slightly higher but hitches frequently feels worse than a path that averages slightly lower but delivers consistent frame times. Smoothness, not peak rate, is what the player experiences moment to moment, and any comparison that reports only an average is incomplete.

The fourth misconception is that one comparison settles the question permanently. Drivers, game patches, and settings changes all move the answer. A good comparison is dated, versioned, and repeatable, and it is revisited after major updates rather than treated as a permanent verdict.

A Practical Decision Framework

Use the following sequence when a game offers more than one modern API. First, check whether the game or its documentation recommends a default, and start there, because the default is usually the path that received the most testing. Second, run the controlled comparison described above in a representative scene at actual play settings, with each path warmed up, and compare frame-time consistency as well as average rate. Third, weigh stability alongside speed: a path that crashes, flickers, or shows missing effects is not a candidate, however fast it appears in a short test. Fourth, consider the system's balance: on a CPU-limited system, give extra weight to parallel submission paths; on a GPU-limited system, expect smaller differences and prioritise whichever path is most stable. Fifth, record the choice and the versions tested, and re-check after a major driver or game update, especially if smoothness changes.

If all paths feel equivalent in the controlled test, keep the default. There is no prize for choosing the more exotic option, and the default path is the one most likely to receive prompt fixes if a future update causes trouble. If one path is clearly smoother in the test route and stable across several runs, use it, but remember that the result is specific to the tested game, driver, and hardware. Do not generalise it to other titles.

Related boundaries, in one line each: legacy compatibility for much older titles is a separate topic from modern API choice; first-run shader stutter explains compilation hitches in depth; frame-generation latency is separate from base API submission efficiency; and update-regression comparison gives the method for re-testing after a driver or game update changes behaviour.

FAQ

If a game offers DirectX 11, DirectX 12, and Vulkan, which should I try first?

Start with the game's default. The default path usually received the most testing and driver attention. Then run the controlled same-scene comparison in this guide if smoothness is unsatisfactory, rather than switching on reputation alone.

Why does DirectX 12 sometimes hitch when a new effect appears?

A new effect can require a new pipeline state object that has not been created or cached yet. Creating it during gameplay can stall the frame. Warming the cache by playing through the relevant content, or using a pre-compilation step where the game offers one, reduces this. Persistent hitching after warm-up points to a different cause.

Does Vulkan work the same way on every system?

No. Vulkan is explicit and cross-platform, but engine effort, driver maturity, and advertised optional features vary. Two systems running the same game under Vulkan can behave differently, which is why the comparison must be made on the actual system and driver in use.

My GPU is fully busy. Will changing API help?

Probably not much. When the GPU is the bottleneck, the limiting factor is shading and pixel work, not how fast the CPU submits commands. API choice matters most when the CPU cannot feed the GPU fast enough, which shows up as a waiting GPU and a saturated submission thread.

Should I re-test after a driver update?

Yes. Driver updates can change pipeline handling and invalidate cached pipelines, forcing recompilation. Re-run the same scene and settings after a major driver or game update, and compare against notes from the previous version before concluding that an update helped or harmed performance.

Is a built-in benchmark enough to choose an API?

A benchmark is a useful supplement, but a scripted camera path may not match interactive play or warm caches the same way. Combine a benchmark with a repeatable in-game route at actual play settings, and give more weight to frame-time consistency than to a single average figure.

Conclusion

Choosing between DirectX 11, DirectX 12, and Vulkan in the same game is an exercise in understanding contracts, not in picking a winner. DirectX 11 trades CPU submission headroom for driver-managed forgiveness. DirectX 12 and Vulkan trade forgiveness for parallel submission and explicit control, and they reward engines that create pipelines efficiently and cache them well. The fastest choice on one system, driver, and game version may not be the fastest on another, and it can change after an update. A short, controlled, same-scene comparison, warmed up per API, recorded with frame-time consistency in mind, and noted with versions, will answer the question for the system in front of you far more reliably than any general ranking. Keep the default when paths tie, keep notes when they do not, and re-check after updates.