NVIDIA VBIOS Vix Loader: 800 W on an RTX 5090 Without Flashing the Card

By Indie Kings | October 19, 2026

Updated October 19, 2026: A developer known as Panchovix has released loaders that run a modified VBIOS on NVIDIA graphics cards without flashing the card, per VideoCardz. The tools cover GeForce RTX 50, RTX 40 and RTX 30 series cards, with experimental support for Turing, and the demonstrations include an RTX 5080 running a 500 W power limit and an RTX 5090 at 800 W. The original firmware stays on the card, which is the interesting part and also the part that does not make the modification safe.

VideoCardz graphic for the RTX 5080 500 W power limit test

Image credit: VideoCardz.

What changed

Modifying a graphics card's VBIOS has meant writing a new firmware image to the card's flash chip, with all the risk that implies. The tools Panchovix published take a different route, per VideoCardz: save the card's original VBIOS, edit a copy, and have the driver load that copy instead. The flash chip is never written.

Three pieces ship together. The NVIDIA VBIOS Vix Editor changes power limits, voltage limits, clock offset ranges and fan settings, per VideoCardz. A Windows loader puts an edited image in front of the driver, and a Linux loader does the equivalent through NVIDIA's open kernel modules. The Windows and Linux loaders are separate GPL-3.0 projects, each published in the last week of October with their own READMEs.

That distinction is the whole story. A VBIOS edit normally changes what the card believes about itself until someone flashes it back. This workflow changes what the driver hands the card at startup, and the card's own firmware is still there underneath. Unloading the override returns the driver to the stock image.

The Windows path: registry override and a GPU restart

The Windows loader writes the edited image into the GPU's driver registry key, where the NVIDIA driver looks for a VBIOS override when the device starts, per the project's README. It stores the image chain from the legacy image to the end of the last image as a binary value, sets the firmware mode to allow the override, deletes any leftover override records, reads the values back, and restarts the GPU with a device restart command.

Three commands cover the workflow. Load applies the image, verify checks that the driver is actually running it, and unload removes it again. The README is explicit that the flash chip is never written, and that unload returns the key to its state before the first load, with one exception: if another tool wrote an override first, the loader says so and leaves that tool's firmware setting in place.

There is a lineage behind it. Both loaders credit a user called pantsoftime on overclock.net, whose original override work the project family is built on, per the READMEs. The Windows README also notes that the registry values it writes are the same ones mVolt+ uses when it loads a BIOS file, so a BIOS loaded with mVolt+ on the same GPU is replaced, and the project states it is not affiliated with mVolt+.

Driver support is narrow and stated plainly. The Windows loader works with NVIDIA 616.x and 617.x drivers, 616.56 or newer, tested on 617.42 and 617.70, per the README. The README warns that it may stop working in a future driver if NVIDIA changes or removes the registry override, and tells users to run verify after every driver update.

The Linux path: patched open kernel modules and a second boot entry

The Linux loader approaches the same problem from the kernel side. It patches NVIDIA's open kernel modules so the GSP firmware starts with the chosen VBIOS image, builds them in a separate boot entry, rebuilds them automatically after kernel updates, and keeps the normal boot entry as a fallback, per its README. The image is loaded in memory at boot and the flash chip is still never written.

That fallback design is the part worth understanding. If the loader cannot confirm its own modules, or an offline profile is in use, or a source check mismatches, it moves its modules aside and boots the newest normal entry whose NVIDIA module was built for the new driver version. The machine boots without the override rather than not booting at all, per the README.

Support is honest about its edges. The supported configuration is Fedora 43 with GRUB and BLS, dracut, DNF5, and NVIDIA 615.x open kernel modules installed with the driver's own installer. The RHEL family, Debian and Ubuntu, Arch and its derivatives, systemd-boot, unified kernel images and Secure Boot are experimental, tested in synthetic and container environments only. Drivers from a package manager are experimental as well, while rpm-ostree, proprietary NVIDIA kernel modules and drivers older than 615 are not supported.

The tested hardware list is longer than the platform list: RTX PRO 6000 Blackwell Max-Q, RTX PRO 6000 Blackwell Workstation Edition, GeForce RTX 5090, 5080, 5070 Ti, 5070, 5060 Ti and RTX 2000 Ada. Ada cards carry a specific constraint, because GSP firmware loads at most 512 KiB counted from the payload's legacy image, so Ada payloads have to be relocated with the editor. The laptop Ada images the team tested were refused, four because they do not fit and one because it carries no UEFI image.

The power limits demonstrated so far

VideoCardz reports three working demonstrations. All three are configured power limits, not measured power draw and not performance results, and the distinction belongs in every sentence about them.

Card	Stock limit	Loaded limit	What the source adds
GeForce RTX 5090	600 W	800 W	Demonstration reported by VideoCardz
GeForce RTX 5080	360 W	500 W	Demonstration reported by VideoCardz
GeForce RTX 4090	550 W	671 W	Per the Windows loader README, a core clock offset range of +1200 MHz was applied in the same test

Source: VideoCardz, October 19, 2026, and the Windows loader README. These are configurable limits, not measured gaming power consumption or performance gains.

The same editor can move in the other direction. VideoCardz notes that the tools can lower power consumption beyond the usual software limits, and the Windows README records an Ampere test on an RTX A2000 where a lowered power floor of 5 W was applied. The editor exposes power limits, voltage limits, clock offset ranges and fan settings, so the use case is not only more watts.

None of these numbers describe a card running a game. A power limit is a ceiling the driver enforces, and raising it changes what the card is allowed to draw, not what it does draw in a given scene. Anyone reading 800 W as a measured figure is reading it wrong, which is why VideoCardz flags the distinction in its own report.

Which cards are covered

The two loaders do not cover the same hardware, and the Windows README's status table is the clearest statement of where testing has actually happened.

Family	Windows loader	Linux loader	Notes
Blackwell GB20x (RTX 50, RTX PRO Blackwell)	Tested on an RTX 5070, driver 617.42	Tested on 5090, 5080, 5070 Ti, 5070, 5060 Ti, RTX PRO 6000 Blackwell Max-Q and Workstation Edition	Windows uses the same registry values as mVolt+
Ada AD10x (RTX 40, RTX Ada)	Tested on an RTX 4090, VBIOS 95.02.18, driver 617.42	RTX 2000 Ada tested, other desktop Ada experimental, laptop Ada images refused	Ada payloads must be relocated for the 512 KiB GSP load limit
Ampere GA102 to GA107 (RTX 30, RTX A series)	Tested on an RTX A2000, driver 617.42, power floor lowered to 5 W	Same 512 KiB GSP load limit applies per the project notes	Other Ampere cards untested
Turing TU102 to TU117 (RTX 20, GTX 16, TITAN RTX, Quadro RTX, T series)	Experimental, not tested on any Turing GPU	Not in the tested list	If the override is refused, the card runs its stock VBIOS
GA100 (A100, A30, A800)	Not supported	Not supported	The README excludes these explicitly

Sources: the Windows and Linux loader READMEs, fetched October 19, 2026.

The gaps in that table are the useful information. Turing is experimental and untested, which means nobody has confirmed that the Windows driver runs GSP firmware on those cards and applies the override there. If it does not, the card simply boots its stock firmware. Blackwell and Ada have real hardware tests behind them, and so does one Ampere workstation card.

What the tool does not do

The Windows loader does not flash the card, does not edit the VBIOS, and does not change clocks, fans or power limits by itself, per its README. It loads an image that someone else produced with the editor. That separation is deliberate: the loader is a transport mechanism, and the editor is where every decision about power and voltage happens.

That also means the loader cannot be described as a performance tool. Nothing in either README claims a frame rate, a benchmark gain or a stability improvement. The measurable claims in the project family are about what the driver will accept and what the card will report afterward, which is why the verify step exists.

Risk, and why a driver update can end this

Both READMEs carry the same warning in almost the same words: a modified VBIOS can raise power, clocks and voltages beyond the card's design limits, you can damage hardware, keep a copy of your original ROM, and use it at your own risk. VideoCardz repeats the practical version: instability, overheating, excessive current through power connectors, permanent damage, and the point that an untouched original VBIOS does not make the modification safe.

The driver dependency is the other structural risk. The Windows loader's support statement is explicitly conditional, 616.x and 617.x tested, with the README telling users to verify after every driver update because NVIDIA may change or remove the registry override. The Linux loader has the same shape: run the status command after a driver update and check an edited value such as the power limits reported by the management tool.

That makes this a workflow rather than a permanent unlock. It works while the driver cooperates, and the projects say so instead of implying otherwise. The Windows README goes further and documents how to get back: unload removes the override, restores the firmware setting it changed, and restarts the GPU.

FAQ

Does this flash my graphics card?
No. Both loaders leave the flash chip untouched, per the project READMEs. The Windows loader stores the edited image in the GPU driver's registry key and restarts the device, and the Linux loader patches open kernel modules so the firmware starts with the image in memory at boot.

Which NVIDIA cards are supported?
GeForce RTX 50, RTX 40 and RTX 30 series per VideoCardz, with Blackwell, Ada and Ampere carrying real hardware tests in the README tables. Turing is listed as experimental and untested, and GA100 cards such as the A100, A30 and A800 are explicitly unsupported.

Does it work on Linux?
Yes, through NVIDIA's 615.x open kernel modules, per the Linux loader README. Fedora 43 with GRUB, DNF5 and the driver's own installer is the supported configuration; RHEL, Debian, Ubuntu, Arch, systemd-boot and Secure Boot are experimental, and proprietary modules or pre-615 drivers are unsupported.

Can it raise my power limit?
Yes. The demonstrations include an RTX 5090 at 800 W instead of 600 W and an RTX 5080 at 500 W instead of 360 W, per VideoCardz. These are configured limits, not measurements of gaming power draw or performance.

Will it survive a driver update?
Not guaranteed. The Windows loader is tested on 616.x and 617.x drivers from 616.56 upward, and its README warns that NVIDIA could change or remove the override, so users should verify after each update. The Linux loader asks users to check its status command after driver updates for the same reason.

Is it safe?
No one involved says so. Both READMEs warn that a modified VBIOS can exceed the card's design limits and damage hardware, and VideoCardz lists overheating, connector current and permanent damage as risks. Keeping a copy of the original ROM is the documented minimum precaution.

Our take

The interesting engineering here is not the wattage, it is the reversibility. Flashing a VBIOS has always been a one way door with a recovery procedure behind it, and moving the same edit into the driver turns it into a switch with an unload command. That is a better shape for experimentation, and the projects deserve credit for documenting the fallback path as carefully as the feature.

I would not touch an 800 W setting on a 5090, and the README's own warning is the reason. What I would watch is whether the editor's downward direction gets more attention, because lowering a power floor on a handheld or a small form factor card is a legitimate use that does not require heroics with a power connector. The other thing to watch is NVIDIA. A registry override that survives driver releases by accident is a different product from one that is tolerated, and the next few driver branches will tell us which this is.

Bottom Line

Panchovix's Windows and Linux loaders run a modified NVIDIA VBIOS without writing the card's flash chip, per VideoCardz and the project READMEs. The editor changes power limits, voltage limits, clock offset ranges and fan settings, and the loaders put the result in front of the driver: a registry override and GPU restart on Windows, patched open kernel modules and a separate boot entry on Linux. Demonstrated configurations include an RTX 5090 at 800 W, an RTX 5080 at 500 W and an RTX 4090 at 671 W, all configured limits rather than measured draw. Testing is real on Blackwell and Ada and experimental on Turing, the tools carry explicit hardware damage warnings, and the whole method depends on driver behavior NVIDIA has not committed to preserving.

Sources: VideoCardz, "NVIDIA GeForce 50/40/30 GPUs can now load custom VBIOS without flashing, RTX 5080 tested at 500W," October 19, 2026. Project READMEs and repositories, fetched October 19, 2026: NVIDIA Windows VBIOS Vix Loader, NVIDIA Linux VBIOS Vix Loader, NVIDIA VBIOS Vix Editor.