Two Graphics Cards, Double the Speed? Why SLI and NVLink Are Dead, What DX12 Multi-GPU Actually Does & Whether a Second Old Card Is Worth It

2026-10-24 ｜ GPU Repair ｜ About 16 minutes ｜ HK GPU Fix Editorial Team

重點摘要

Two graphics cards do not automatically mean twice the speed. Old driver-level SLI and NVLink are effectively finished, DirectX 12 multi-GPU only works when the game itself implements it, and a second old card is idle in most games. This guide explains the mechanisms, the checks, and the upgrade decision.

The Short Answer First

Two graphics cards in one machine do not automatically work together on one game, and they do not automatically double performance. That single sentence prevents most of the disappointment around second cards. The old system, known as SLI on NVIDIA cards and CrossFire on AMD cards, was a driver-level arrangement: the graphics driver split the work of one frame between two cards. The newer system, DirectX 12 and Vulkan native multi-GPU, is a completely different arrangement: the game itself decides how to use two cards, with no driver profile and no bridge doing the job in the background. Confusing those two systems is the root of most wrong purchases. A buyer who expects the new system to behave like the old one, or who expects either system to work automatically in every game, will end up with a second card that sits idle, draws power, generates heat, and adds nothing to the game on screen.

This guide keeps three questions separate throughout. First, what did the old system actually do, and why did it stop? Second, what does the new system actually do, and why is it rare? Third, when, if ever, does buying a second old card make sense, and when is selling the old card and buying one stronger single card the sounder choice? Those questions have different answers for games, for rendering and compute work, and for a machine where a second card simply runs a second screen or a streaming encoder. Keeping the use case fixed is essential, because a statement that is true for gaming can be false for rendering, and vice versa.

How Old Driver-Level Multi-GPU Worked

In the SLI and CrossFire era, the driver was in charge. The game itself was generally written as if it were running on one graphics card. The driver intercepted the work, divided it, and handed parts to each card, then combined the results for display. Two division methods dominated, and understanding them explains almost everything that followed, including the stutter, the profile dependency, and the memory behaviour.

The first method was alternate frame rendering, usually shortened to AFR. Card A rendered one complete frame, card B rendered the next complete frame, card A rendered the one after that, and so on. Each card worked on a whole frame in turn. The second method was split frame rendering, usually shortened to SFR. The screen was divided, for example into an upper and a lower portion, and each card rendered its own portion of the same frame at the same time. Some variations divided the screen in other ways, but the principle was the same: one frame, two workers, each handling a defined share.

Both methods required constant communication between the cards. Each card needed to know what the other was doing, and the combined result had to be assembled in the right order and at the right time. The bridge connector, first the SLI bridge and later NVLink on high-end NVIDIA cards, provided a dedicated high-speed path between the cards for that exchange, reducing the amount of traffic that had to travel over the PCIe bus. The bridge was therefore a communication channel, not an accelerator in its own right. Without a game or a driver arrangement that actually used two cards, a bridge on its own did nothing to speed up a game. That point matters because bridge hardware is sometimes described in sales listings as if fitting it were itself an upgrade. It was not. It only mattered once two cards were already cooperating on the same workload.

The driver also had to know, game by game, how to divide the work safely. That knowledge came in the form of a driver profile: a set of instructions prepared by the graphics card maker for a particular game, telling the driver how to split frames, how to synchronise the cards, and how to handle the special rendering techniques that game used. A game without a profile could not be split reliably. In that case the driver typically left the second card idle, and in some cases attempting to force multi-GPU on an unsupported game produced flickering, missing effects, black screens, or performance worse than a single card. The profile was therefore not a minor optimisation. It was the precondition for the whole arrangement to work at all.

Why Video Memory Does Not Add Up

The most persistent misunderstanding about two cards is also the easiest to state clearly: two cards with 8GB of video memory each do not make a 16GB card. Under the old driver-level arrangement, each card had to hold its own copy of the scene resources it needed, including textures, models, and buffers. If card A was rendering a frame, it needed the full set of resources for that frame. If card B was rendering the next frame, it needed the same set. Neither card could borrow the other's memory as if the two pools were one larger pool. The usable memory for the game was therefore effectively the memory of one card, not the sum of both.

This has a practical consequence that buyers often miss. A game that needs more video memory than one card provides will not be fixed by adding a second card of the same memory size. The bottleneck is the per-card memory capacity, and that capacity is unchanged by the second card. A buyer whose real problem is running out of video memory at a chosen resolution and texture setting needs a single card with more memory, not a second card with the same amount. Conversely, a buyer whose game runs within one card's memory but wants higher frame rates may still not benefit from a second card, for the separate reason of game support, which is covered below. Memory and frame rate are different limits, and a second card addresses neither automatically.

Why Alternate Frame Rendering Could Feel Worse Than It Looked

Average frame rate is a poor summary of smoothness, and nowhere was that clearer than with alternate frame rendering. Suppose two cards together produced a high average frame rate. That average said nothing about the spacing between individual frames. If one card finished its frame quickly and the other took longer, the intervals between frames on screen became uneven: short, long, short, long. The eye perceives that uneven spacing as stutter, even when the headline number looks impressive. This uneven spacing is commonly called micro-stutter.

Micro-stutter was not simply a matter of a driver being poorly written in some abstract sense. It followed from the structure of the arrangement. Two independent cards, each rendering whole frames in turn, had to stay in step, and any variation in how long a frame took on one card showed up directly as irregular pacing. Split frame rendering avoided that particular problem, because both cards worked on the same frame, but it introduced its own difficulty: dividing a frame evenly is hard when one part of the scene is far more complex than the other, and the finished frame could only be displayed once the slower portion was done. Either way, the cooperation itself created a new class of timing problems that a single card did not have.

That is why a sensible check after installing a second card is not the average frame rate alone. Frame time stability, meaning how consistent the interval between frames is, matters at least as much. A supported game that shows a higher average but visibly uneven pacing is not necessarily a better experience than a single card with a lower average and steadier pacing. Any comparison that reports only an average, without saying anything about pacing, is incomplete for this subject.

Why Profiles Mattered, and Why New Profiles Stopped

The profile system worked only while the graphics card makers kept writing profiles, and that effort had a cost that grew as games became more complex. Modern rendering techniques, including deferred rendering, complex post-processing, and temporal effects that depend on previous frames, are harder to split between two cards than the simpler rendering of earlier years. Each new game could require new work to divide correctly, and that work had to be repeated for a shrinking audience, because fewer and fewer players were running two cards.

NVIDIA's public transition, described in its support material on SLI support moving to native game integrations, set a clear marker: from 1 January 2021, no new SLI profiles would be created for the RTX 20 series and earlier generations. Existing profiles would continue to be maintained and tested, but new games would not receive new profiles. That distinction is important and is often misstated. It does not mean that an old card with an existing profile suddenly stopped working on the day the policy changed. A supported older game with an existing profile could continue to use that profile. What it does mean is that the pipeline for new games closed. A game released after that point, without a profile, should be treated as unsupported by the old system unless its own developers implemented native multi-GPU support, which is a different matter covered in the next section.

On the RTX 30 series, only a small number of high-end models retained an NVLink connector, and those models supported only the native game integration mode, not the old driver profile mode in the same way. Later consumer generations dropped the NVLink connector for consumer cards. AMD, meanwhile, had already been stepping back from CrossFire for gaming over a similar period. The direction on both sides was the same: the driver-profile model for games was being wound down, not refreshed.

Three forces pushed in the same direction. First, the audience shrank, because a single mid-range or high-end card became sufficient for mainstream resolutions, so the group of players who needed two cards to reach playable performance narrowed. Second, the cost of two cards rose in every dimension at once: purchase price, power supply capacity, cooling, case space, and noise, all roughly doubled or increased substantially, while the benefit applied to fewer and fewer games. Third, low-level graphics APIs changed who was responsible for multi-GPU, shifting that responsibility from the driver to the game developer, as explained below. Any one of those forces alone would have weakened the old system. Together, they ended it as a mainstream gaming proposition.

DirectX 12 and Vulkan Native Multi-GPU: A Different System Entirely

DirectX 12 and Vulkan multi-GPU, often shortened to mGPU, must not be described as a new name for SLI. It is a different system with a different owner. Under the old system, the driver divided the work and the game did not need to know about two cards. Under the new system, the game code itself decides how to use two cards, and the driver does not divide the work behind the game's back. There is no driver profile to write, and no bridge is required, because the game manages the cards through the API directly.

That shift explains both the promise and the rarity of native multi-GPU. In principle, a game developer has far more freedom than a driver profile ever allowed. In practice, that freedom comes with work that few developers can justify for a small fraction of players. The developer must write code to distribute work, manage resources across cards, synchronise results, and test the result on multiple card combinations. A bug in that code affects only the small group of multi-GPU players, yet it can still generate support reports and damage the game's reputation. For most studios, the return on that investment is poor, which is why the number of games with genuine native multi-GPU support remains very small, even though the capability has existed in the APIs for years.

Two sub-modes of native multi-GPU are worth distinguishing, because they are often blurred together in casual discussion. The first is the linked, or implicit, mode. In this mode, two similar cards are presented to the game as one linked group, and the game can use a shared pool of resources across them in the way the API allows. Even here, the performance gain is not automatic. The game still decides how to use the group, and a poorly designed use of the group can gain little or nothing. The second is the explicit, or unlinked, mode. In this mode, the game treats each card as a separate adapter and assigns different work to each, for example rendering on one card and a separate compute or post-processing task on the other. This mode can even mix different cards, including a discrete card and an integrated graphics processor handling different jobs. It is the most flexible mode, and also the hardest to implement well, which is why real examples are rarest of all.

The practical test for a buyer follows directly from that structure. Before buying a second card for a particular game, check that game's own official documentation, release notes, or developer statements for an explicit statement of DirectX 12 or Vulkan multi-GPU support. A general statement that the game uses DirectX 12 is not such a statement. DirectX 12 is an API, and using it does not imply multi-GPU support. A statement that the game supports multi-GPU, naming the mode or describing how the second card is used, is the evidence to look for. No such statement should be read as meaning no support. Guessing, or relying on a forum post that claims support without a source, is how a second card ends up idle.

After installation, the same principle gives a direct observation test. Use a monitoring tool to watch the utilisation of both cards while the game runs. If the second card remains near zero utilisation while the first card is heavily loaded, the game is not using the second card, whatever the settings menu may suggest. That observation is evidence of non-support, not evidence that a driver setting has been missed. Where a game does support multi-GPU, both cards should show sustained activity during gameplay, and frame time pacing should be checked as well as average frame rate, for the reasons given earlier.

A Note on Terminology: Power Daisy-Chains Are a Different Subject

The word daisy-chain appears in two unrelated graphics card discussions, and they should not be confused. In power supply discussion, a daisy-chain cable is a single power supply cable that splits into two connectors for a graphics card, sharing one conductor path. That subject concerns current, voltage drop, and connector heating, and it is about how one card is powered. In the present guide, the subject is whether two separate cards cooperate on one game. A power cable arrangement does not make two cards cooperate, and a bridge or multi-GPU setting does not change how a card's power cables should be arranged. Readers who arrive here from a power question should treat the two topics separately and check each on its own terms.

Layered Diagnosis: When the Second Card Does Nothing

A second card that appears to do nothing should be investigated in layers, from hardware upward, without skipping steps. Skipping to a conclusion, such as assuming the card is faulty, wastes time and can lead to an unnecessary repair request for a card that is working correctly on its own.

The first layer is hardware. Confirm that both cards are fully seated in their PCIe slots, that their power cables are connected as the card and power supply makers require, and that the system firmware recognises both cards. The operating system's device listing should show two graphics adapters before any discussion of multi-GPU can begin. If the second card does not appear there at all, the problem sits at the slot, power, or motherboard level, not at the game level. Reseating the card, trying the other slot where the motherboard allows it, and checking the power connections are the appropriate early steps, all performed with the machine powered off and disconnected from mains power. If the card is not recognised in any slot and on its own, that is a different finding from a card that is recognised but unused by a game, and the two findings lead to different next steps.

The second layer is the driver. Confirm that the installed driver version supports the card combination in question. For old-style SLI, the control panel should offer a multi-GPU option for a supported combination. If no such option appears for that card and driver, the usual reading is that the combination is not supported, not that a setting has been overlooked. Installing an older driver in the hope of reviving a profile is not a safe general remedy, because older drivers may lack fixes and support for other software, and the profile pipeline for new games is closed regardless.

The third layer is the game, and it is where most cases of an idle second card are resolved. Check, as described above, whether the game has an old-style profile, for an older title, or native multi-GPU support, for a newer title. If neither exists, the second card will remain idle in that game, and no driver setting, bridge change, or reinstallation will create support that the game does not contain. This is the most common cause, and it is also the most frequently misdiagnosed, because an idle card looks like a fault when it is in fact the expected behaviour for an unsupported game.

The fourth layer is performance, and it applies only once support is confirmed. Check frame time stability, not average frame rate alone. Check whether the gain is consistent across scenes, or whether it appears only in a simple scene and disappears in a complex one. Check whether the system remains stable over a sustained session, because a configuration that works for a few minutes and then stutters or crashes under heat is not a successful configuration. A supported setup that is unstable or uneven may still be a worse experience than a single card, and that judgement should be made on the full picture, not on a single number.

Boundary Cases That Change the Answer

The statement that SLI is dead must be qualified, or it will mislead readers whose work is not gaming. The qualification is simple: what ended was driver-profile multi-GPU for games. Multi-card work in other fields never depended on that system in the same way, and it remains meaningful there.

Rendering, scientific computing, and machine learning training are the clearest examples. A renderer or a compute framework that is designed to split its task across cards does so at the application level, assigning separate frames, tiles, or data batches to each card. That splitting does not need a game profile or a bridge, and it does not suffer from the game-specific timing problems described above, because the work is not a single interactive frame that must be displayed at a fixed cadence. A second card for such work is a genuine second worker, and the decision is about throughput, memory per card, power, and cooling, not about game support. Readers in those fields should therefore not read this guide's gaming conclusion as a statement about their work.

A second boundary is a machine that contains two cards without linking them for gaming at all. A second card can drive an additional screen, can handle video encoding for streaming while the main card renders the game, or can run a compute task independently. None of those uses requires SLI or native multi-GPU support, because the cards are not cooperating on one frame. They are simply two independent devices in one machine, each doing its own job. That distinction also explains why a second card can be useful in a machine even though it adds nothing to a particular game's frame rate. Usefulness and game speedup are different claims, and both can be true of the same machine for different tasks.

A third boundary is the old card with an old game. A player who already owns two older cards, and who plays an older game that does have an existing SLI profile, may still find that the old arrangement works for that game. This guide does not claim that every old profile vanished. It claims that the pipeline for new profiles closed, and that new games should not be expected to gain support. A buyer who is considering purchasing a second old card specifically for an old supported game should still count the full cost: the card itself, plus any power supply upgrade, cooling, case space, and the risk of running an older driver. Those supporting costs are part of the price, even when they are not on the card's price tag.

A fourth boundary is PCIe lane allocation. On many motherboards, the second full-length slot does not run at the same lane width as the first. It is common for the second slot to run at eight lanes or four lanes, depending on the board and on what else is installed. That allocation is stated in the motherboard manual's lane table, and it should be checked rather than assumed. A narrower second slot does not automatically make a configuration unusable, but it does affect the bandwidth available for card-to-card traffic and for the second card's own data, and it is one more reason to check the motherboard documentation before buying.

The Upgrade Decision: Three Questions Before Spending Anything

The decision between buying a second old card and selling the old card to buy one stronger single card can be reduced to three questions, asked in order. If any question cannot be answered clearly, the purchase should wait until it can.

First, does the software you actually use state, in its own official documentation, that it supports multi-GPU in a form your cards can use? For a game, that means an old profile for an old title, or native support for a newer title. For a renderer or compute tool, that means the tool's own documentation describing multi-card operation. A vague impression that multi-GPU should work is not an answer to this question.

Second, does the rest of the machine support a second card without further upgrades that change the economics? That includes the power supply's capacity and connectors, the cooling capacity of the case, the physical space for a second card and its airflow, and the motherboard's lane allocation. If any of those requires an upgrade, the cost of that upgrade belongs in the comparison, not outside it.

Third, what is the total cost of each path? On one side, the price of a second old card plus any power, cooling, or case upgrades it requires, plus the ongoing cost of higher power draw and heat. On the other side, the price of a single stronger card minus whatever the old card can be sold for, with no second-card overhead. In most gaming cases, the single-card path is lower in total cost, simpler to cool, easier to support, and compatible with every game, not only the few that support multi-GPU. That is why the general recommendation in this guide favours the single-card path for gaming, while leaving the multi-card path open for compute and rendering work where the software is designed for it.

Misconceptions, Corrected in One Place

The first misconception is that two cards mean double the video memory. As explained above, each card holds its own copy of the resources, so the usable memory is that of one card, not the sum. A memory-limited game is not fixed by a second card.

The second misconception is that buying another old card is always a cheaper upgrade than replacing the card. It is cheaper only if the rest of the machine needs no upgrade and the target games support multi-GPU. Once a power supply upgrade, extra cooling, or a larger case is required, the total cost can exceed the price difference of a single stronger card, while still leaving most games unsupported.

The third misconception is that a second card that does nothing in a game must be faulty. In most cases the cause is non-support by the game, not a hardware fault. A card that works correctly on its own, displays normally, and is recognised by the system is not faulty merely because a particular game does not use it alongside another card.

The fourth misconception is that an NVLink bridge is a universal accelerator. A bridge is a communication channel between cards. Without game or software support for using two cards, the bridge itself does not make a game faster. Buying a bridge without confirmed support is spending money on a channel with nothing to carry.

The fifth misconception is that because DirectX 12 exists, every DirectX 12 game supports multi-GPU. DirectX 12 provides the capability; each developer decides whether to implement it. The absence of an explicit multi-GPU statement for a game should be treated as non-support for purchasing purposes.

The sixth misconception is that SLI has vanished entirely, including for old games and for non-gaming work. Existing profiles for old games remain where they existed, and application-level multi-card work in rendering and computing never depended on game profiles. The end of new game profiles is not the end of every multi-card use.

When Inspection Is Warranted, and When It Is Not

A hardware inspection is warranted when a card shows signs of a fault on its own, independent of multi-GPU. That includes a card that is not recognised in any slot, a card that produces a black screen or patterned corruption when running alone, or a card that fails in the same way regardless of which slot it uses. Those symptoms point toward the card itself, and they are worth investigating as hardware questions in their own right.

An inspection is not warranted as a remedy for an unsupported game. If a card works normally on its own, displays correctly, and is recognised by the system, but a particular game does not use it alongside a second card, no inspection will create game support. The game either supports multi-GPU or it does not, and that is a property of the game's code, not of the card's health. Sending a healthy card for inspection on that basis will not change the game's behaviour, and the time is better spent on the upgrade decision described above.

If inspection is needed, the workshop is at Shek Mun Dali Plaza Room 1209, reachable by phone on 2186 8010 or by WhatsApp on 6558 6806. Diagnostic and repair fees follow the published three-tier range of HK$400–2,800, with the actual figure confirmed after inspection. There is no Mong Kok shop and no on-site service.

Frequently Asked Questions

Do two 8GB cards give me 16GB of video memory?

No. Under the old driver-level arrangement, each card holds its own copy of the scene resources, so the usable memory for the game is effectively that of one card. A game limited by video memory needs a single card with more memory, not a second card of the same size.

Is SLI completely dead, even for old games?

Not in that absolute sense. From 1 January 2021, NVIDIA stopped creating new SLI profiles for the RTX 20 series and earlier, but existing profiles continued to be maintained. An old game with an existing profile may still use it. What ended was the pipeline for new games, so a new game should not be expected to gain old-style support.

Does DirectX 12 mean a game supports two cards?

No. DirectX 12 provides the capability for a developer to implement multi-GPU, but each developer must do that work for their own game. Only a game whose own documentation states multi-GPU support should be treated as supporting it.

My second card shows near-zero utilisation in a game. Is it broken?

Most likely not, if the card works normally on its own. Near-zero utilisation in a game that does not support multi-GPU is the expected behaviour. Check the game's own support statement first, and test the card alone before concluding there is a fault.

Should I buy a second old card or sell mine and buy one stronger card?

For gaming, the single stronger card is the sounder choice in most cases, because it benefits every game, not only the few that support multi-GPU, and it avoids the extra power, heat, and space of a second card. The second-card path makes sense mainly where the target software explicitly supports multi-GPU, or where the second card has a separate job of its own.

Can a second card help if it is not linked for gaming?

Yes, for separate jobs. A second card can drive another screen, handle streaming encoding, or run a compute task independently, without any SLI or native multi-GPU support, because those jobs do not require the cards to cooperate on one game frame.

Does an NVLink bridge make any game faster on its own?

No. A bridge is a channel for card-to-card communication. Without game or software support that actually uses two cards, the bridge carries nothing that speeds up the game, and buying one without confirmed support does not create that support.