GPU Control Panel Settings Explained: NVIDIA Control Panel & AMD Adrenalin Key Options

2026-10-23 ｜ GPU Repair ｜ About 34 minutes ｜ HK GPU Fix Editorial Team

Summary

Control panel settings work in two layers, global defaults and per-game profiles, while sync, latency, power and image quality switches interact with each other, so record original values first, change one item at a time, and verify with controlled comparisons.

First, the conclusion: the control panel is a settings map, not a one-click speed button

Opening the NVIDIA Control Panel or AMD Adrenalin software for the first time usually produces the same question: among dozens of options, which ones are actually worth changing? Lists of so-called best settings circulating online often tell readers to push everything to maximum or minimum in one pass, and the result is frequently disappointing. Games do not get faster, and instead users see flicker, stutter, fans spinning up for no clear reason, or a problem that appears in only one game. The fault is usually not one individual option being right or wrong. The control panel is not a one-click speed button. It is a map of settings, and every option acts on only one stage of the rendering chain, so changing one stage shifts the balance of the whole chain.

The most useful starting point is not memorising each option definition one by one. It is understanding the stages a frame passes through before it reaches the screen. A game engine first works out what each frame should contain, then hands instructions to the graphics driver, and the driver schedules the graphics processor to carry them out before the finished frame is passed to the display. Most control panel settings intervene at the driver stage. Some decide when a finished frame is handed to the display. Some decide how many instructions are queued before the graphics processor executes them. Some decide how aggressively the graphics processor raises its clocks. Some decide how finely image details are rendered. At the same time, games have their own graphics options, and driver-level options can overlap, stack, or conflict with them. Once this division of labour is clear, it becomes possible to judge where each setting should be changed.

This article walks through the map layer by layer: global settings versus per-game profiles, the switching logic for vertical sync and variable refresh rate, latency-related options, power management modes, image quality options, shader cache and pre-rendered frames, the boundary between sharpening and upscaling, how to verify a change with controlled comparisons, and how to restore defaults when a change goes wrong. It deliberately does not repeat three companion articles. Which driver branch to choose belongs to the article on driver selection. The underlying causes of screen tearing and the deeper principles of vertical sync belong to the article on tearing and sync. The principles and brand-by-brand comparison of upscaling technologies belong to the upscaling article. The job of this article is to give readers a complete map of the control panel itself, so that every switch can be placed on the right stage, with a clear sense of when to touch it and when to leave it alone.

One premise must be stated before any setting is touched. Control panel settings solve setting-level problems. If a graphics card has a hardware fault, such as unstable power delivery, failed cooling, or memory errors, no combination of settings will repair it, and aggressive settings may even mask the symptoms for a while until the fault becomes worse. This article therefore covers setting logic and verification methods only, and never presents any setting as a repair method. If a problem persists after settings have been restored, and it appears regularly, for example a black screen that always appears under heavy load or visual corruption fixed to one particular scene, that is the point to stop adjusting settings and arrange an inspection to judge whether the cause is hardware.

Layer one: global settings versus per-game profiles, and which one wins

In the NVIDIA Control Panel, 3D settings are split into Global Settings and Program Settings. In AMD Adrenalin software, the same idea appears as global graphics settings and per-game profiles. Brand names differ, but the logic is identical: global settings are the defaults, and per-game profiles are exceptions. When a dedicated profile exists for a game, that game uses the profile values while it runs, and only falls back to global settings for items the profile does not specify. In other words, a per-game profile outranks global settings, and this priority order is the single most important rule on the whole map.

This rule explains an extremely common confusion: a user changes vertical sync or power mode in global settings, launches a game, and sees no change at all. The most frequent cause is that the game already has its own profile, and the relevant item in that profile still holds the old value. Because the dedicated profile wins silently, the global change is covered over, and the screen looks as though the setting did nothing. Conversely, if no profile has ever been created for that game, a global change takes effect immediately. Before changing any setting, therefore, the first step is not to change a value in a hurry. It is to confirm whether the panel currently being edited is the global page or one particular game profile. Otherwise every comparison test that follows will be unreliable.

The second rule concerns the relationship between in-game settings and driver settings. Many games offer their own vertical sync, frame rate cap, and quality preset options, and these in-game options usually control engine behaviour directly. A driver-level option of the same kind may override the game setting, stack on top of it, or be ignored by the game, depending on how that option is designed. The general principle is that an item which can be set inside the game should preferably be set inside the game, because the game developer knows the engine behaviour best. Driver settings are best used for cases the game does not offer, or where the in-game setting fails to work. For example, if a game already offers a frame rate cap, there is no need to add a second cap at driver level, because two caps operating together can make frame times unstable. Conversely, if an older game offers no vertical sync switch at all, forcing it at driver level is a reasonable way to fill the gap.

The third rule is that the smaller the scope of a change, the easier it is to verify. A global setting affects every game at once, so if something goes wrong, each game must be checked to find which one is affected. A per-game profile affects only that one game, so the scope of any problem is immediately obvious. The stable practical approach is therefore to experiment in a per-game profile first, confirm that the change works without side effects, and only then consider whether it is worth promoting to global settings. This matters especially for image quality options such as anisotropic filtering or texture quality, because different games differ greatly in how sensitive they are to quality versus performance, and no single quality value suits every game. Global settings are best reserved for genuinely universal items that the user is sure every game should share, such as the shader cache size limit or the general direction of power management.

One habit is worth building: before changing any setting, record the original values. A photograph of the settings page, or a short written note listing which items changed and from what to what, takes only a few dozen seconds. When a change goes wrong, that record is the only reliable basis for restoring it. The restore-defaults function can wipe a whole page, but if only one item needs restoring while other items have already been tuned, a missing record forces guesswork item by item, and guessing is a reliable way to restore the wrong value.

Vertical sync, G-Sync and FreeSync: three different jobs

Vertical sync, G-Sync and FreeSync are constantly discussed as though they were one thing, but they govern different stages. Vertical sync governs when the graphics card hands a frame to the display. With it on, the card waits until the display has finished one refresh before handing over the next frame. With it off, the card hands over each frame as soon as it is drawn, without waiting for the display. G-Sync and FreeSync belong to variable refresh rate technology, and they govern when the display refreshes. Instead of refreshing a fixed number of times per second, the display follows the rhythm at which the graphics card delivers frames. One governs the timing of frame delivery, the other governs the timing of display refresh. They only work well together, and switching on one of them is not the same as switching on all of them.

This division of labour directly determines the switching logic. The most common stable combination starts in the display menu: variable refresh rate is switched on there first, then G-Sync or FreeSync is switched on at driver level, and finally vertical sync and the frame rate cap are chosen according to game type. Inside the variable refresh rate range, the display follows the graphics card rhythm, and tearing is already greatly reduced. Adding vertical sync inside that range mainly acts as a backstop, preventing tearing from returning when the frame rate breaks through the top of the range and the card starts delivering frames too fast. Many players therefore pair variable refresh rate with a frame rate cap set a few frames below the display maximum refresh rate, keeping the frame rate inside the variable refresh rate range for most of the time, so that vertical sync becomes a safety net rather than the main mechanism. The point of this combination is that all three items must be considered together. Switching on only one of them and then declaring it ineffective often means the other two were never set to match.

If the display itself does not support variable refresh rate, the situation becomes much simpler, because only vertical sync remains to choose. With vertical sync on, frames are complete, but the frame rate is locked to whole-number divisions of the display refresh rate, and the perceived drop is more obvious when the frame rate falls below the refresh rate. With vertical sync off, the frame rate is free, but frames may tear. There is no perfect combination in this case, only a trade-off: choose sync for frame completeness, or choose freedom and low latency and use a frame rate cap to narrow the fluctuation. One further point deserves emphasis. Variable refresh rate is not switched on by the graphics card alone. The display must support it, the cable must meet the required specification, and the corresponding function in the display menu must be switched on before the whole chain works. If any link is missing, switching it on at driver level will have no effect, and this is the most frequent reason users believe the setting is broken.

Another easily overlooked detail is that full-screen and windowed modes can behave differently. Some variable refresh rate settings take effect only in full-screen mode, while borderless windowed or pure windowed modes follow a different path. If a setting appears to work in full-screen mode but behaves differently in windowed mode, the setting may not have been changed at all. The display mode itself may simply have a different effective range. Comparison tests must therefore always use the same display mode, or the results cannot be compared. The same caution applies to dual-display setups. When the primary and secondary displays have different refresh rates, variable refresh rate behaviour can be affected, so the primary output display should be noted before testing begins.

A boundary should be drawn here. This article covers switching combination logic, meaning which switch governs which stage and how they should be paired. Why tearing appears, why vertical sync affects input latency, and why unsynchronised frame rates and refresh rates produce tearing are matters of principle, and the companion article on tearing and vertical sync covers them in full. They are not repeated here. Readers who cannot yet tell tearing apart from stuttering will move faster by reading that principles article first, then returning to the combination table here to apply settings.

Latency: Low Latency Mode, Anti-Lag, and maximum pre-rendered frames

Latency is often reduced to a single slogan, that switching on a low-latency mode makes everything faster. Reality is more complicated, because many queuing stages sit between a mouse click and the corresponding change on screen, and different low-latency options intervene at different stages. NVIDIA Low Latency Mode, AMD Anti-Lag, and in-game options such as Reflex all aim to reduce queuing, but their points of action and conditions of use differ, so they cannot be treated as the same switch under different names.

To understand latency, it helps to understand why queuing exists at all. So that the graphics processor never sits idle, a game engine usually prepares instructions for several upcoming frames in advance and lines them up for the graphics processor to work through one by one. A longer queue keeps the graphics processor busy and frame rates steadier, but the price is that a current input must wait until the older frames already in the queue have been processed before it appears on screen. This is the trade-off behind the pre-rendered frames setting. More pre-rendered frames mean a steadier frame rate but a later response to input. Fewer pre-rendered frames mean a faster response to input but a higher chance of graphics processor idle time and more frame rate fluctuation. The driver setting for maximum pre-rendered frames, and the AMD Flip Queue Size setting, govern how long this queue is allowed to be.

Low Latency Mode and Anti-Lag approach the same queue from different stages. In simple terms, they try to stop the game engine from preparing too many future frames at once, or to make the driver hand over instructions closer to the moment they are actually needed, thereby shortening the distance between input and screen. These options show their clearest benefit when the graphics processor has spare capacity and the frame rate is already high. When the graphics processor is already fully loaded and the frame rate is already low, shortening the queue may not improve perceived response at all, and may even increase frame rate fluctuation because of added idle time. A low-latency option is therefore not a universal remedy. Its value depends on where the current bottleneck sits. If the bottleneck is an overlong queue, shortening the queue helps. If the bottleneck is graphics processing power itself, no amount of queue shortening will create processing power.

Another common confusion is to treat low-latency options and vertical sync as the same thing. Vertical sync affects when frames are handed over. Low-latency options affect how long the instruction queue is. The two can operate at the same time, and they interact in the final perceived result. For example, once vertical sync is on, frame handover must wait for the display, and queue behaviour itself changes, so the effect of adding a low-latency option can differ markedly from its effect with sync off. Testing a low-latency option therefore requires vertical sync and the frame rate cap to be held fixed, or it becomes impossible to tell which switch caused any perceived change. The practical recommendation is to change one item at a time, and to judge it with the same scene and the same action before drawing a conclusion.

The priority of in-game options applies here as well. If a game already provides Reflex or a similar built-in low-latency option, that in-game option should generally be used first, because the game engine understands its own queue structure best, and the driver-level generic low-latency mode is a fallback. Switching both on at once risks double intervention and can make frame times unstable. This is the same principle stated earlier for in-game settings generally. What the engine can do itself should not be stacked again at driver level.

Power management mode: is maximum performance always right?

Power management mode is another frequently misunderstood option. Many users assume that setting power management to maximum performance makes the graphics card run at full speed forever, so games must get faster, while adaptive or power-saving settings must make games slower. In reality, power management mode governs how aggressively graphics clocks rise and fall as load changes. It does not directly set the maximum clock the card can reach. That maximum is set by hardware design and cooling conditions. Power mode cannot change that ceiling. It only affects how quickly clocks climb towards it, and how quickly they fall back when load drops.

On a desktop computer, the effect of power mode is usually small, because power supply and cooling headroom are relatively generous, and the graphics card quickly climbs to high clocks under gaming load and stays there. In that situation, the actual in-game frame rate difference between maximum performance and adaptive mode is often too small to notice. The main price of maximum performance is paid at idle and under light load, when the card holds higher clocks than necessary, so temperature and fan speed stay higher for longer, and fan noise and power draw both increase. If a machine shows fans repeatedly spinning up while idle on the desktop, power mode is one of the items worth checking.

On a laptop, power mode matters far more. Laptop cooling and power headroom are already tighter, and the system adds its own layers: a system power plan, a battery mode, and a manufacturer performance mode. Driver-level power settings only make sense in combination with those layers. For example, plugged-in and battery-powered states can follow completely different system power strategies, and battery protection at system level can still limit output even when driver power is set to maximum performance. Laptop users testing power mode must therefore note whether the machine is plugged in or on battery, and which system power plan is active. Otherwise the same driver setting can give completely different results under different power states, and comparisons become meaningless.

The stable way to treat power mode is as a tool of elimination, not as a performance switch. If intermittent stutter is suspected, and other causes have been ruled out, power mode can be changed from adaptive to maximum performance for one controlled comparison in the same scene, to see whether the stutter follows the rhythm of clock changes. If the stutter does not change, the bottleneck is probably not power management, and the setting should be restored while other stages are examined. Maximum performance should never be left on permanently simply because it sounds strongest. Permanently high idle clocks are not good for cooling or fan lifespan, and once a genuine cooling problem appears, high idle clocks will make it surface sooner.

Image quality options: texture filtering, anisotropic filtering, and shader cache

Among image quality options, the most confusing pair is texture filtering quality and anisotropic filtering. Both relate to texture sharpness, but they govern different stages. Texture filtering quality mainly decides how finely the graphics card samples and blends textures when scaling them, so higher quality gives smoother edges on distant or angled textures, at the cost of more computation. Anisotropic filtering specifically handles textures viewed at a shallow angle, such as ground stretching away from a standing viewpoint. Without it, distant ground turns into a blur. With it, distant texture detail holds up better. Stacking the two improves image quality more noticeably, but the performance cost stacks as well, so pushing both to maximum in one pass and then complaining about the frame rate drop misses the point.

A steadier order of work is to set anisotropic filtering to a moderately high level first, for example eight times or sixteen times, and judge whether the visual gain is worth it, before touching texture filtering quality. Anisotropic filtering gives the most visible improvement in angled scenes, while texture filtering quality improvements are subtler and may not be obvious in a moving game image. If the machine is already tight on performance, anisotropic filtering should usually be kept and texture filtering quality sacrificed, because the former typically gives the better visual return. Conversely, if the game mostly presents static images where texture detail itself matters, texture filtering quality can move up the priority list. The point is to test the two separately, never bound together in one change, or it will never be clear which one caused a frame rate drop.

The shader cache is a setting of a different kind. When a game loads a new scene or a new effect for the first time, the driver must compile shaders once, and that compilation causes a brief pause, commonly called a shader compilation stutter. The shader cache stores compiled results, so that the next time the same scene loads, the stored result is used directly without recompiling. The driver setting for shader cache size governs the ceiling of that storage space. A cache set too small means older compiled results are discarded quickly, and re-entering a scene requires compiling again. A sensibly sized cache means the second and later entries into a scene run noticeably smoother. This setting has little effect on the maximum frame rate, but a clear effect on smoothness when entering scenes and changing locations.

The shader cache is not a cure-all, however. After a driver update, an older cache may become invalid and require recompiling once, which is normal behaviour, not a sign that the driver update failed. A major game update, a change of graphics card, or a change of driver branch can also invalidate the cache. A simple way to judge whether a stutter is shader-cache related is to enter the same scene twice. If the first entry stutters and the second entry is smooth, compilation stutter is a likely explanation. If the same location stutters every time in exactly the same way, other causes should be considered, such as scene loading itself or storage speed, rather than blaming the cache. Which driver branch to choose, and when a driver should be updated, is covered in full by the companion article on driver selection, and is not repeated here.

The boundary for sharpening and upscaling: far enough is enough

Sharpening and upscaling are the pair most likely to be switched on together in one pass, and the pair most in need of a clear boundary. Sharpening is straightforward. It strengthens edge contrast on an image at its existing resolution, making the picture look crisper. Upscaling works completely differently. It renders at a lower internal resolution, then enlarges the result to the target resolution with an algorithm, trading less computation for a picture close to native resolution. One processes the original image, the other changes the rendering resolution and then enlarges it. Their costs and side effects are fundamentally different, and they should never be treated as two names for the same switch.

On the control panel map, sharpening and upscaling sit at the post-processing layer, and should only be considered after basic settings are already stable. The common mistaken order is to switch on upscaling first to chase frame rate before basic settings are settled, then find the picture too soft and add sharpening to compensate, then push sharpening too far and produce white edges and noise, until the whole picture has been adjusted step by step into a worse state with no clear record of which step started the problem. The correct order is the reverse. Set sync, latency, power, and basic quality at native resolution first, confirm that picture and frame rate are stable, and only then ask whether upscaling is genuinely needed to gain extra frame rate. If the answer is yes, switch on one upscaling solution, either in-game or at driver level, never both. If the picture then feels too soft, add only light sharpening, starting from a low strength, never jumping straight to maximum.

One further boundary must be stated. Upscaling is not a free lunch for image quality. The lower the internal resolution, the more frame rate is gained, but the more fine detail is lost, especially small text, distant objects, and fast-moving scenes. The reasonable use of upscaling is to gain a playable frame rate when performance is insufficient, not to stack it on top of already sufficient performance in pursuit of a higher number. The principles of each upscaling solution, suitable games, and image quality comparisons are covered in full by the companion upscaling article, and are not rewritten here. The conclusion readers need at control panel level is simple: sharpening and upscaling are post-processing options. Do not change them together with basic sync, latency, and power settings, and never switch on the same function in both the game and the driver at once.

How to verify a change: a controlled comparison is the only verdict that counts

The most dangerous mindset when changing settings is to change ten items at once on the basis of feeling, and then declare the result smoother or worse. Feeling alone is unreliable, because perception of frame rate changes with the scene, with mood, and even with the previous session. The stable verification method is a controlled comparison: hold every variable fixed, change exactly one variable, and measure before and after with the same method. The method sounds demanding, but in practice it takes only a few minutes, and it is the only way to state which setting actually made a difference.

A complete controlled comparison holds several items fixed. First, fix the test scene: the same game, the same level, the same location, and the same route, ideally using a built-in benchmark mode where the game provides one, or a fixed route of the user's own where it does not. Second, fix in-game settings: quality preset, resolution, and display mode must not move during the test. Third, fix driver settings: apart from the single item under test, every other item keeps its original value. Fourth, fix the measured indicators: do not look only at average frame rate, but also at frame time fluctuation, minimum frame rate, temperature, and power draw, because a high average frame rate with wildly varying frame times still feels like stuttering. Fifth, repeat the test: run the same test twice, and only trust results that are close across both runs. If two runs differ greatly, some other variable is not yet fixed, and that variable must be found before any conclusion is drawn.

For measurement tools, the performance overlay provided by the driver itself is already sufficient for basic comparisons, covering frame rate, frame time, graphics processor utilisation, temperature, and clocks. The choice of tool matters less than looking at the same set of numbers every time under the same standard. As an example, to test whether changing power mode from adaptive to maximum performance helps, the method is: run a fixed scene once on adaptive mode and record average frame rate, frame time fluctuation, and temperature; switch to maximum performance and run the same scene again, recording the same set of numbers; place the two sets side by side before deciding whether the change is worth keeping. Running once and declaring the result smoother on feeling alone does not count as verification.

One further trap in controlled comparisons is a test scene that is too short or too easy. Standing in an empty location looking at the sky places almost no load on the graphics card, and no setting change will show a difference there. A test scene must contain genuine load: many characters on screen together, complex lighting, and rapid view changes, because those are the conditions under which settings actually make a difference. Conversely, if everyday play never reaches that kind of load, a difference found under extreme load may have no practical meaning for that user. The purpose of a controlled comparison is not to find the theoretically strongest setting, but to find the setting genuinely worth keeping under the user's own style of play.

Restoring a bad change: no panic, restore layer by layer

A bad settings change is not a cause for panic, because the control panel itself provides restoration mechanisms, and the restoration levels match the setting levels just as clearly. The lightest restoration is item by item: if the changed items were recorded, each one is returned to its original value. This method is the most precise, and it depends entirely on having recorded original values before changing anything, which is why that habit was stressed earlier. The middle level is per-game restoration: the profile of the affected game is restored to defaults, while other games remain untouched. This suits cases where only one game shows a problem. The most thorough level is global restoration: every setting is wiped back to defaults. This suits cases where the user no longer remembers what was changed, or the problem has spread across many games. The levels should be tried from lightest to heaviest, never jumping straight to the heaviest, or previously tuned settings will be wiped together with the bad change.

In the NVIDIA Control Panel, global settings and program settings each have their own restore-defaults option. In AMD Adrenalin software, global graphics settings and per-game profiles can likewise be restored separately. One point must be noted before restoring: restoring defaults only restores control panel settings. It does not restore in-game settings, and it does not restore display menu settings. If a problem involves in-game settings and the display menu as well, restoring driver settings alone is not enough, and all three layers must be checked separately. A practical isolation order is: first restore the driver profile of the affected game and test once; if the problem remains, check whether in-game settings were also changed; if it still remains, check the display menu and cable. Checking layer by layer has the advantage that every step can identify which layer the problem came from, instead of wiping the whole panel and still not knowing where the fault was.

If the problem remains after defaults have been restored, it is time to pause and consider whether the problem is in the settings layer at all. A damaged driver installation, damaged game files, a compatibility problem after a system update, or even a developing hardware fault can all present as a problem that no setting change fixes. Continuing to try random control panel changes at that point only makes isolation more confused. The more reasonable next step is to record the symptoms: which game is affected, under what action it appears, whether it appears in the same place every time, and whether any specific error message appears. Those symptom descriptions are the basis for judging whether the next check should be the driver, the game files, or the hardware. If symptoms are regular and load-related, for example a black screen or restart fixed to heavy load, hardware inspection should be seriously considered rather than further settings changes.

One follow-up action belongs after any restoration: restoration is not complete until it has been verified. After restoring, the user's usual scene should be run again using the controlled comparison method, confirming that picture and frame rate have returned to their pre-change level, before the restoration counts as finished. If the experience still feels wrong after restoration, some layer may have been missed, such as an in-game setting or the display menu, and the layers should be compared once more. The goal of restoration is not settings that look tidy, but actual performance returned to a known good state. Performance is the final judge.

Common mistakes, stated plainly

The first mistake is pushing every option to maximum and calling that the best setup. Maximum quality options cost performance. Switching every sync option on costs latency and compatibility. Maximum power costs temperature and noise. The control panel has no combination in which everything at maximum is best. There is only the most balanced combination for one particular machine, one set of games, and one display. A list that tells readers to push a dozen options to maximum in one pass, without stating its conditions of use, should be questioned before it is followed.

The second mistake is stacking driver settings on top of in-game settings. A frame rate cap switched on in both places, vertical sync in both places, a low-latency option in both places, or upscaling in both places are all classic examples of double intervention. Double intervention may not cause an immediate failure, but it makes frame times hard to predict, and when a problem appears, it becomes impossible to tell which side should be switched off. The principle is simple: one function should be switched on at one layer only, with the other layer left at default or off. Which layer takes priority was stated earlier. In-game first, driver as fallback.

The third mistake is treating a change as finished without testing it. Some control panel effects appear immediately, some only appear in particular scenes, and some side effects only appear after running for a while, such as temperature slowly climbing or fans slowly speeding up. Looking at the main menu once after a change and calling it done is not verification. At minimum, a loaded scene should be run for several minutes, with temperature and frame times observed, before a setting can be said to hold on that machine.

The fourth mistake is mixing settings problems with hardware problems. Settings can solve trade-off problems at settings level: frame completeness versus frame rate freedom, image quality versus performance, latency versus stability. Settings cannot solve hardware-level faults: insufficient power, failed cooling, memory errors. The boundary is clear. Settings problems usually change immediately when a setting changes, and the change follows a pattern. Hardware problems usually show the same symptom no matter how settings change, and the symptom worsens with load or over time. Failing to see this boundary leads to circling inside settings while missing the moment when inspection is actually needed.

The fifth mistake is ignoring the display and the cable. Variable refresh rate, refresh rate ceilings, and colour output all depend on the display and cable working together. Driver-level variable refresh rate switched on, but the display menu function off, or a cable that does not meet the required specification, means the function simply will not work. When isolating a fault, the display menu and cable should be checked together with driver settings, not left out while circling inside the control panel.

Frequently asked questions

Q: Global settings were changed, but nothing changed in the game. What should be checked first?

A: Check whether the game has its own profile first. If a dedicated profile exists, its values outrank global settings, and the global change will be covered over. Next, check whether the game has a similar in-game option, because overlapping in-game and driver settings may not follow the driver value. Only then consider whether the driver setting itself was not saved or did not take effect.

Q: G-Sync or FreeSync is switched on, but feels no different. Does that mean the setting failed?

A: Not necessarily. First confirm that the display itself supports variable refresh rate, that the corresponding function in the display menu is switched on, and that the cable meets the required specification. Next confirm that frame rates in the test scene sit inside the variable refresh rate range, because effect is reduced when frame rates stay above the top or below the bottom of the range. Finally confirm the display mode is full-screen, because some settings take effect only in full-screen mode.

Q: Should a low-latency mode be left on permanently?

A: It depends. If the game already provides a built-in low-latency option, use the in-game option first, and do not stack the driver-level generic mode on top. If graphics processor capacity is spare and reaction speed matters, a driver-level low-latency mode usually helps. If the graphics processor is already fully loaded and frame rates are already low, it may not help, and may even make frame rates fluctuate more. Decide with a controlled comparison, not by the name of the option.

Q: Will setting power management to maximum performance always make games faster?

A: Not necessarily. Power mode affects how aggressively clocks rise and fall, not the maximum clock ceiling. On a desktop computer under gaming load, the frame rate difference between maximum performance and adaptive mode is usually small, and the main price of maximum performance is higher temperature and fan speed at idle and under light load. On a laptop, the picture is more complex, because the system power plan and plugged-in state also apply, so driver settings alone do not decide the result.

Q: Is a larger shader cache always better?

A: A sensibly sized cache makes the second and later entries into the same scene smoother, because compiled results do not need rebuilding. But a cache is not better without limit. After a driver update or a major game update, an older cache may become invalid and require compiling once, which is normal. If the same location stutters in exactly the same way every time, the cause may not be the cache, and other causes should be considered.

Q: After a bad settings change, what is the safest restoration order?

A: From lightest to heaviest: first restore item by item the values recorded before the change; if that fails, restore the profile of the affected game; only if the problem has spread across many games should global restoration be used. After restoring, run a usual scene to confirm performance has returned to its pre-change level before counting the restoration as finished. Restoring driver settings does not restore in-game settings or display menu settings, so those two layers must be checked separately.

Q: What should be done if a graphics card hardware problem is suspected?

A: Stop pushing settings further. Record the symptoms: which game, what action, whether it happens in the same place every time, whether it relates to heavy load, and whether any error message appears. The machine can then be brought in for inspection at Shop 1209, Dali Plaza, Shek Mun. The telephone number is 2186 8010 and WhatsApp is 6558 6806. Do not take the card apart or alter hardware before inspection, so that diagnosis is not affected.