How to Tune Game Graphics Settings for the Biggest FPS Gain? Per-Setting GPU, CPU & VRAM Cost Explained

2026-10-26 ｜ GPU Repair ｜ About 15 minutes ｜ HK GPU Fix Editorial Team

重點摘要

Tuning graphics settings blindly wastes time because each setting taxes a different part of the machine: some load the GPU's shaders, some fill VRAM, and some load the CPU with draw calls. This guide ranks settings by what they cost, explains the mechanism behind each cost, and shows a controlled one-change-at-a-time comparison method.

The Short Answer First

Most graphics menus present settings as if they were interchangeable dials, each one worth about the same. They are not. A texture setting mainly changes how much video memory is occupied and how much data must be moved. A shadow setting mainly changes how much shading work the GPU must repeat. A view-distance setting can change how many objects the CPU must prepare for drawing, as well as how much the GPU must draw. Two settings that look equally important in a menu can therefore pull on entirely different bottlenecks, and lowering the wrong one first can leave the actual limit untouched while making the game look noticeably worse.

The useful question is not "which setting is heaviest in general?" but "which resource is limiting this game, on this machine, in this scene, and which settings consume that resource?" A game limited by shader work will respond to shadow, lighting, and effects settings. A game limited by VRAM capacity will respond to texture quality, and sometimes to resolution. A game limited by CPU preparation work will respond to draw distance, object density, and crowd settings. Change the setting that matches the limit, and the improvement is visible. Change a setting that consumes a resource with spare capacity, and almost nothing changes except image quality.

This guide explains the mechanism behind each major setting, ranks settings by the resource they consume, and then sets out a controlled comparison method that isolates one change at a time. It is deliberately about per-setting cost and comparison method. It does not try to diagnose whether a machine is CPU-limited or GPU-limited in general; that diagnosis has its own guide, article #137, and readers who suspect a bottleneck should start there. Upscaling, frame generation, dynamic resolution scaling, and VRAM overflow are also kept brief here, because each already has its own guide: upscaling in article #162, frame generation in article #175, scaling in article #174, and VRAM overflow in article #156. Where those topics touch this guide, it summarises the point and points past it.

Four Resources, Not One "Performance"

It helps to think of a game as consuming four partly independent resources. The first is GPU compute: the shader work of shading pixels, computing lighting, and running post-processing effects. The second is VRAM capacity: the textures, geometry buffers, shadow maps, and render targets that must fit in video memory at once. The third is memory bandwidth: how quickly data can be moved between VRAM and the GPU, which matters most when many large textures or high-resolution render targets are in play. The fourth is CPU preparation work: deciding what to draw, issuing draw calls, updating animation, physics, and game logic, and preparing data for the GPU.

A setting usually taxes one resource heavily and others lightly, but a few tax several at once. Resolution is the clearest example of a multi-resource setting: raising it increases the number of pixels the GPU must shade, increases the size of render targets in VRAM, and increases the bandwidth needed to move those larger targets around. View distance is another: it increases CPU preparation work because more objects must be considered, and it increases GPU work because more objects are actually drawn. Recognising which resource a setting taxes is the whole skill of tuning, because it tells you which symptom to expect when that resource runs out.

When GPU compute runs out, frame times rise fairly evenly and lowering shader-heavy settings helps. When VRAM capacity runs out, the symptom is different: the game must repeatedly swap data in and out of video memory, and the result is often stutter — brief hitches — rather than a smooth, uniformly lower frame rate. When bandwidth runs out, high resolutions and large textures suffer disproportionately, and lowering resolution or texture size helps more than lowering a compute-heavy setting would. When CPU preparation runs out, the GPU may sit partly idle waiting for work, and lowering GPU-heavy settings does little, because the GPU was never the limit. These symptom patterns are clues, not proofs, and the controlled method later in this guide is how a clue becomes a decision.

Resolution and Render Scale: The Master Multiplier

Resolution is the master multiplier because it scales the pixel count of almost everything the GPU shades. Moving from one resolution step to the next does not merely make the image sharper; it multiplies the number of pixels that must be shaded, lit, and post-processed every frame. That is why resolution is usually the first setting to consider when a large gain is needed, and why it is also the setting whose visual cost is most obvious: lowering it softens the whole image rather than one effect.

Render scale, sometimes labelled resolution scale or render resolution, does the same job more flexibly. A render scale below 100 percent renders the scene at a smaller internal resolution and then scales the result up to the display resolution. The GPU shading load falls with the internal pixel count, while menus and interface elements usually stay at full display resolution. A render scale above 100 percent does the opposite, rendering more pixels than the display needs, which is a form of supersampling and is very expensive.

Two cautions apply. First, resolution and render scale interact with upscaling. A game using an upscaler already renders at a reduced internal resolution and reconstructs a higher-resolution image; changing render scale on top of that stacks two scaling steps, and the result should be judged by image quality as well as speed. Article #162 covers upscaling in full, and this guide does not repeat it. Second, lowering resolution does not help a CPU-limited scene much, because the CPU must still prepare the same objects regardless of how many pixels they occupy. If lowering resolution changes almost nothing, that is evidence the limit lies elsewhere, and article #137 is the next step.

Texture Quality: VRAM Capacity First, Compute Second

Texture quality controls the resolution of the surface images wrapped around game geometry: walls, ground, clothing, weapons, and scenery. High-quality textures are larger files in memory, so their main cost is VRAM capacity and, when textures stream in, memory bandwidth. Their direct shader cost is comparatively small, because sampling a larger texture is not dramatically more work than sampling a smaller one once the texture is in memory.

That profile explains the characteristic behaviour of texture settings. On a machine with ample free VRAM, raising texture quality may cost almost nothing in frame rate, because the GPU already had room for the larger textures. On a machine close to its VRAM limit, raising texture quality can cross the threshold into overflow, where data must be swapped in and out repeatedly, and the result is stutter even if the average frame rate looks acceptable. Lowering texture quality in that situation can remove the stutter without much changing the average frame rate, which is a good trade even though it looks unimpressive on a frame-rate chart.

Texture streaming complicates the picture. Many modern games do not load every texture at once; they load high-detail versions for nearby objects and lower-detail versions for distant ones, and stream new detail in as the player moves. A texture setting that is too high for the available VRAM can therefore cause visible pop-in — distant surfaces suddenly gaining detail as the player approaches — or brief hitches during fast movement. If pop-in or movement hitches are the complaint, texture quality and VRAM are the first suspects, and article #156 explains overflow symptoms and checks in detail.

A practical rule follows: texture quality should be set to the highest level that fits comfortably in VRAM with headroom for the rest of the scene, and judged by stutter and pop-in as well as by average frame rate. It is a poor first choice for fixing a uniformly low frame rate on a machine with spare VRAM, because it consumes a resource that is not the limit.

Shadows: Repeated Shading Work

Shadow quality is usually one of the most expensive settings, and the reason is repetition. To know whether a surface is in shadow, the game must render the scene, or a relevant part of it, from the light's point of view, producing a shadow map. It then compares each visible surface against that map during the main render. Higher shadow quality means larger shadow maps, more detailed shadow-casting objects, longer shadow distances, and softer shadow edges, all of which multiply that repeated work.

Shadow resolution and shadow distance are the two levers inside the setting. A larger shadow map gives crisper edges but costs more memory and more shading work. A longer shadow distance means shadows are computed for objects further away, which adds work for detail the player may barely notice. Soft shadows, which blur the edge between light and shade, add a filtering pass on top. The visual return diminishes quickly: the difference between medium and high shadow quality is often visible on close inspection but modest during play, while the cost difference can be substantial.

Shadows are therefore a strong early candidate when GPU compute is the limit, and a poor candidate when it is not. If lowering shadow quality produces a clear improvement, shader work was part of the limit. If it produces almost nothing, the limit is probably VRAM, bandwidth, or CPU preparation, and the next test should target those resources instead.

Anti-Aliasing, Ambient Occlusion, and Post-Processing

Anti-aliasing smooths the jagged stair-step edges where one surface meets another. Different methods do this job at very different costs. Older methods that render the scene at a higher resolution and downsample it are extremely expensive, because they multiply the pixel count of the whole frame. Modern temporal methods reuse information from previous frames to smooth edges at a much lower cost, but they can introduce their own artefacts, such as ghosting on fast-moving objects or softness in fine detail. The cost of anti-aliasing therefore depends less on the label in the menu than on the method the game actually uses, and the right comparison is between methods in the same game, not between labels across games.

Ambient occlusion adds contact shadows where surfaces meet — in corners, under objects, and in creases — where direct light and shadow maps alone would leave the join looking flat. It works by sampling the nearby geometry around each pixel, which is shader work that scales with resolution and with the sampling radius. High-quality ambient occlusion samples more points and produces subtler, more accurate darkening, but the cost rises with each added sample. Like shadows, it is a GPU compute cost, and it is often a good second candidate after shadows when compute is the limit.

Post-processing is an umbrella for the effects applied to the finished frame: bloom, depth of field, motion blur, lens effects, colour grading, and similar treatments. Each effect is a pass over the whole frame or over a large part of it, so post-processing cost scales with resolution. Individually, most post-processing effects are modest, but a game with many of them enabled can accumulate a noticeable total. Because post-processing is applied after the main scene, it is also a setting whose visual effect is a matter of taste: motion blur and depth of field change the look of the game as much as its speed, so disabling them should be a deliberate choice about image preference, not merely a performance lever.

View Distance, Level of Detail, and Object Density

View distance, draw distance, and level-of-detail (LOD) settings control how far away objects are drawn and how much detail distant objects carry. Their cost is distinctive because it falls on both the CPU and the GPU. The CPU must consider more objects, decide which are visible, and issue the draw calls for them. The GPU must then draw those objects, even if they occupy only a few pixels on screen.

This dual cost makes view distance a powerful setting in open-world and large-scale games, and a weak one in enclosed games where there is little distant geometry to draw. In a corridor or an interior, raising view distance adds almost nothing, because there is nothing far away to reveal. In an open landscape, raising it adds whole settlements, forests, and terrain features that were previously simplified or omitted, and the cost can be large. The visual return also diminishes with distance: objects far away occupy few pixels, so their extra detail is hard to see, while their preparation cost is paid in full.

Object density, crowd density, and vegetation density are related settings with a stronger CPU flavour. More objects mean more draw calls and more animation and physics updates, even before the GPU draws a single extra pixel. In a busy city or a dense forest, density settings can therefore be the first thing to lower when the CPU is suspected, and article #137 explains how to test that suspicion properly. Foliage deserves a special note: grass and leaves are often drawn as many small, overlapping, semi-transparent shapes, which is expensive both to prepare and to shade, because overlapping transparency forces the GPU to shade the same pixel several times. Dense foliage at high quality is frequently one of the most expensive settings in outdoor games.

Reflections, Effects, and Volumetric Lighting

Reflections in non-ray-traced games are usually produced by screen-space techniques, planar reflections, or cube maps, and their cost depends on the method. Screen-space reflections reuse the already-rendered frame to approximate what a reflective surface should show, which is cheaper than rendering the scene again but limited to what is already visible on screen. Planar reflections render the scene a second time from a mirrored viewpoint, which is far more expensive and is therefore usually limited to a few surfaces or a lower resolution. Cube maps are pre-rendered or periodically updated images of the surroundings, and their cost depends on how often they are refreshed. The practical point is that a reflection setting labelled "high" can mean very different work in different games, and the comparison should be made in the same game, in a scene with visible reflective surfaces, rather than assumed from the label.

Particle effects, explosions, smoke, sparks, and weather effects cost GPU compute and, when many particles are simulated, CPU work as well. Their cost is spiky rather than steady: a quiet scene may run well while a busy battle drops sharply, because the particle count jumps. That spikiness is why effects settings are best tested in a busy scene, not in a menu or a quiet corridor. A setting that looks free in a calm moment can be expensive at exactly the moment performance matters most.

Volumetric lighting and volumetric fog simulate light scattering through air, dust, or fog. They work by sampling the light along rays through the scene's volume, which is shader work that scales with resolution and with the number of samples. The visual effect is atmospheric and often striking, but the cost can be high, and the difference between medium and high is frequently subtle in motion. Volumetric settings are a good candidate for lowering when GPU compute is the limit and the scene is foggy or lit by strong shafts of light, because that is where their cost concentrates.

The Per-Setting Cost Table

This table is a map, not a verdict. The same setting can cost different amounts in different games, because engines implement settings differently, and because the scene determines how much work a setting actually triggers. Shadows in a dark interior cost less than shadows in a sunlit open world. Reflections in a game with few reflective surfaces cost less than reflections in a game built around water and glass. The table tells you where to look first; the controlled method below tells you whether the guess was right on this machine.

A Tuning Order That Respects the Limit

A sensible tuning order starts with the setting most likely to match the limit, not with the setting at the top of the menu. If the complaint is stutter and pop-in, start with texture quality and VRAM headroom. If the complaint is a uniformly low frame rate, start with resolution or render scale for a large step, then shadows and volumetric effects for finer steps. If the complaint is slowdowns only in busy or open scenes, start with density and view distance. If the complaint is slowdowns only in busy action, start with effects. Each step should be judged on its own, before the next step is taken, so that the effect of each change is known rather than guessed.

A common mistake is to lower everything at once. Lowering everything at once usually works, in the sense that performance improves, but it teaches nothing: the reader does not learn which setting mattered, the image is worse than it needed to be, and the next game must be tuned from scratch again. A second common mistake is the opposite: lowering one setting by a tiny amount, seeing no change, and concluding that the setting is free, when the real problem is that the change was too small to matter or that the limit lay elsewhere. Settings should be changed in clear steps — for example, from high to medium, or from one resolution step to the next — and judged in a representative scene, not in a menu.

A third mistake is to judge by a single number. Average frame rate hides the difference between a smooth session and a session with repeated hitches. A better judgement uses frame time behaviour over a sustained run: does the game feel steady, do hitches appear at particular moments, and does the worst sustained stretch improve? Built-in benchmarks, where a game offers one, are useful because they repeat the same scene, but they are not the same as gameplay, and a benchmark scene may stress different settings from the scenes the reader actually plays. Manual runs through a representative gameplay stretch, repeated the same way each time, are the more honest test for a reader's own habits.

The Controlled Comparison Method, Step by Step

Controlled comparison means changing one variable at a time and holding everything else fixed. The method below is deliberately boring, because boring is what makes the result trustworthy.

First, choose a test scene and a test route. Pick a stretch of gameplay that represents the complaint: an open landscape for view-distance questions, a busy fight for effects questions, a reflective street for reflection questions, a foggy area for volumetric questions. Walk or drive the same route, at the same pace, facing the same directions as far as possible. Note the time of day and weather in the game, because lighting changes the cost of shadows and volumetrics. If the game offers a built-in benchmark, use it as a second test, but do not let it replace a gameplay route that matches the complaint.

Second, record a baseline. Before changing anything, note the settings exactly as they are, and note how the baseline run feels: steady or hitchy, slow everywhere or only in certain moments. Write the settings down or take a screenshot of the settings screen. A baseline that exists only in memory is easy to lose, and a lost baseline makes every later comparison guesswork.

Third, change one setting by one clear step. Change shadows from high to medium, or render scale by one step, or view distance by one step — not three settings at once. Restart the game if the game requires it for the setting to take effect, and confirm the change actually applied by reopening the settings screen. Some settings require a restart, some apply immediately, and some are overridden by a driver setting or a preset; a change that did not apply is a wasted test.

Fourth, repeat the same route and compare like with like. Judge by the same qualities as the baseline: steadiness, hitches, and the worst moments, not only the average. If the change helped, keep it and note the size of the improvement in plain language — clearly better, slightly better, or no real difference — rather than inventing precision the test cannot support. If the change did not help, revert it: keeping a change that did not help only degrades the image for no benefit.

Fifth, control the confounders. Close background applications that might compete for CPU or disk access during one run and not another. Keep the display refresh rate, V-Sync setting, and frame cap the same across runs, because each of those changes the meaning of the frame-rate reading. Disable dynamic resolution or any automatic scaling during the test, because an automatic system will change the internal resolution between runs and hide the effect of the manual change. Articles #174 and #162 explain scaling and upscaling behaviour in full. Keep the driver settings unchanged across runs, and avoid updating drivers or the game in the middle of a comparison series.

Sixth, repeat a surprising result. If a change produces an unexpectedly large or unexpectedly absent effect, run the comparison a second time before trusting it. A single run can be distorted by a background task, a shader compilation hitch on first load, or a different weather or time-of-day state in the game. A result that survives repetition is a finding; a result that appears once is a hint.

Seventh, record the final combination. Once the useful changes are identified, write down the final settings as a set, so that they can be restored after a driver update, a game update, or a settings reset. A tuned configuration that is not recorded will be lost at the next reset, and the whole process will have to be repeated.

Related Technologies, Briefly, and Where They Belong

Upscaling reconstructs a higher-resolution image from a lower-resolution render, trading a small quality cost for a large reduction in shading work. It is powerful, but it is a separate system from the individual settings in this guide, and its quality and behaviour depend on the upscaler and its quality preset. Article #162 covers it in full, and readers who have not yet tried upscaling should read that guide before treating resolution as the only way to gain speed.

Frame generation inserts synthesised intermediate frames between genuinely rendered frames, raising the displayed frame rate without raising the rate at which the game itself renders. It changes how smoothness is perceived and how input latency behaves, and it has its own trade-offs and requirements. Article #175 covers it, and this guide does not repeat that analysis. Dynamic resolution scaling automatically adjusts internal resolution to hold a target frame rate; it is useful as a safety net, but it must be disabled during controlled comparisons, because it changes the very variable the test is trying to hold fixed. Article #174 covers it.

VRAM overflow deserves a brief restatement here because it is so often misread as a general slowness problem. Overflow means the data the game needs does not fit in video memory, so data must be swapped in and out during play. The signature is stutter and pop-in rather than uniform slowness, and the remedy is to reduce VRAM-hungry settings — texture quality first, then resolution and shadow map size — rather than to lower every setting indiscriminately. Article #156 explains overflow symptoms and checks in detail.

Finally, a brief word on the bottleneck question. If lowering GPU-heavy settings changes almost nothing, and lowering CPU-heavy settings also changes little, the limit may be elsewhere: a frame cap, a V-Sync setting, a background task, or a genuine CPU or GPU bottleneck of a kind that settings alone cannot fix. Article #137 sets out how to distinguish those cases properly, and this guide deliberately does not reproduce that diagnosis. The controlled method above is the evidence that feeds that diagnosis, not a replacement for it.

Five Misconceptions, Corrected

"Lowering everything to low is the fastest way to tune." It is the fastest way to gain speed, but the slowest way to learn anything, and it leaves the image worse than necessary. One change at a time finds the setting that mattered and preserves everything else.

"Texture quality is always expensive." Texture quality is expensive in VRAM, not necessarily in frame rate. With spare VRAM it can be nearly free; near the VRAM limit it can cause stutter that looks like a completely different problem.

"Resolution is just about sharpness." Resolution multiplies shading work, render-target size, and bandwidth together. It is the largest single lever in most games, and the one whose visual cost is most broadly visible.

"A higher average frame rate always means a better result." Average frame rate hides hitches. A configuration with a slightly lower average but no stutter feels better than a configuration with a higher average interrupted by repeated hitches, especially in VRAM-overflow cases.

"If a setting change does nothing, the setting is broken." A change that does nothing usually means the setting taxes a resource that is not the limit, or that the change did not actually apply, or that the test scene did not trigger the setting's work. Each of those is a useful finding, and each points to a different next test.

Frequently Asked Questions

Question: Which single setting usually gives the biggest gain?

Answer: Resolution or render scale, because it multiplies the pixel count of almost everything the game shades. It is also the setting with the most broadly visible image cost, so it should be judged by image quality as well as speed, and combined with upscaling only after reading article #162.

Question: Why does lowering textures sometimes remove stutter without raising average frame rate much?

Answer: Because the problem was VRAM capacity, not shader speed. When textures fit, the game stops swapping data in and out during play, so hitches disappear even though the average rendering speed barely changes. Article #156 explains VRAM overflow in full.

Question: Why does a setting help in one game but not another?

Answer: Because engines implement settings differently and scenes trigger different amounts of work. Shadows in a dark interior cost less than shadows in a sunlit open world, and reflections matter only where reflective surfaces are visible. Compare settings within the same game and scene, not across games by label.

Question: Should I test in a benchmark or in gameplay?

Answer: Use both where possible. A built-in benchmark repeats the same scene reliably, which is good for comparison, but it may not stress the settings that matter in the scenes you actually play. A repeated manual route through representative gameplay is the more honest test for your own habits.

Question: Why must dynamic resolution be off during testing?

Answer: Because it changes internal resolution automatically between runs, which hides the effect of the manual change you are trying to measure. Disable it for the comparison series, then decide separately whether to use it as a safety net in normal play. Article #174 covers dynamic scaling.

Question: My game is slow only in busy fights. Which settings should I try first?

Answer: Effects and particle settings, and then object and crowd density, because those are the settings whose work spikes when many things happen at once. Test in a busy scene, not in a quiet corridor, because a quiet scene will not trigger the cost you are trying to measure.

Question: My game is slow only in open landscapes. Which settings should I try first?

Answer: View distance and level of detail, and then vegetation density, because those are the settings whose work grows with how much distant scenery is drawn and prepared. If enclosed scenes run well and open scenes do not, the distance settings are the prime suspects.

Question: When should I stop tuning settings and look for another cause?

Answer: When clear, single-setting changes across GPU, VRAM, and CPU-heavy settings all produce little change, or when the symptom survives every settings combination. At that point the cause may be a frame cap, a V-Sync or refresh-rate setting, a background task, or a hardware bottleneck, and article #137 sets out how to distinguish those cases.

Getting Help in Hong Kong

If tuning by the method above leaves a symptom that settings cannot explain — for example, stutter that appears in every game regardless of settings, or a game that behaves differently after a settings reset with no settings change — the cause may sit below the settings layer, in drivers, storage, cooling, or hardware. Note the settings tested, the test scene and route, and which single changes helped and which did not, and bring the machine in for inspection. HK GPU Fix is at Shek Mun, Dali Plaza, Room 1209. The phone number is 2186 8010 and WhatsApp is 6558 6806. There are no home visits and no Mong Kok shop. Inspection pricing follows the published three-tier range of HK$400 to HK$2,800, with a final quote after inspection.