open-gpu-kernel-modules

@latentone_ It seems like a race between slow monitors (G95NC takes about 2s to negotiate the link) and Nvidia's drivers giving up too quickly, and Gnome/Mutter racing with those changes. open-gpu-kernel-modules#1505

Okay, the fix is confirmed on my PC, submitted a PR: open-gpu-kernel-modules#1505

RTX 5090 Local AI - reviewed 25 October 2026 RTX 5090 Local AI Reported benchmarks, practical configurations, and known issues Reader’s guide · Evidence reviewed 25 October 2026 The clearest starting point is a model that fits comfortably in GPU memory. Larger models can work by keeping some weights in system RAM, but their responsiveness depends much more on the host computer, runtime and offload settings. Experimental engines expand what is possible; their best results should be read alongside their configuration and reproducibility limits. This guide brings together published measurements and issue reports. It explains what those reports suggest, rather than promising a particular speed on your machine. Several useful tests date from before August 2026; their dates appear beside the results. Jump to: [What fits?](#what-fits-on-one-card) · [What needs RAM?](#what-needs-substantial-system-ram) · [What needs extra work?](#what-requires-troubleshooting-or-experimental-software) · [Benchmark reference](#benchmark-reference) · [Source notes](#source-notes-and-limitations) The practical picture |Your priority|Configuration to investigate|What to establish first| |:-|:-|:-| |A straightforward baseline|A quantized model reported to run fully on one 5090|Enough spare VRAM for your context length and runtime buffers| |A larger model|Expert offload to system RAM|RAM capacity, memory bandwidth and time to process a long prompt| |Faster generation|A compatible multi-token prediction head|Whether it improves your workload in the runtime version you use| |Longer conversations|A smaller checkpoint or a lower-precision KV cache|Output quality at the context lengths you actually need| |Experimental performance|A specialist offload engine|Exact conversion recipe, published build and a reproducible test| These are editorial starting points drawn from the reports below, not a ranking of model quality. A model that generates quickly may still be the wrong choice for your coding, writing or vision tasks. What fits on one card? The benchmark collection includes several models that ran with their weights resident on a single 32 GB RTX 5090. Examples include Qwen3.6-27B Q4_K_M, Qwen3.6-35B-A3B UD-Q4_K_M, Nemotron-3-Nano-30B-A3B Q4_K_M and Gemma 4 12B Q6_K. Their reported generation rates vary widely, partly because the models do different amounts of computation per token. Benchmark collection File size is only the first part of the memory budget. The runtime also needs working space and memory for the conversation’s KV cache—the stored attention information used during generation. A checkpoint that loads at a short context may run out of memory at a longer one. The quant-selection study documents failures near the memory ceiling even when the weights themselves fit. Quant-selection study For a first comparison, use a resident configuration as your baseline and record both how quickly an answer starts and how quickly it continues. Then test the same workload at your normal conversation length. The short-context figures in the reference table are useful orientation, but they do not establish long-context performance or answer quality. What needs substantial system RAM? Large models with expert offload Mixture-of-experts models can keep some expert weights in system RAM while using the GPU for other work. The reports show usable generation from models much larger than the card’s VRAM, with a significant dependency on memory placement and prompt processing. One Flash-Next test used a 78.9 GB checkpoint and about 59 GB of system RAM. With llama.cpp b10853 and --n-cpu-moe 22, it reported 59.7 generation tokens/s, falling to 51.0 at 32k context. Moving more weights onto the GPU eventually reduced performance or prevented loading. That is evidence for tuning the split on the tested machine, not a universal setting for every 5090. Benchmark collection The Mistral Small 4 report gives another example: approximately 36 generation tokens/s, using about 27.5 GB of VRAM and 46 GB of system RAM. Its prompt-processing rate was about 313 tokens/s. A model can therefore feel responsive once it begins answering while still taking considerable time to read a long input. Detailed offload report DeepSeek: a feasibility experiment with clear limits A Basalt developer’s DeepSeek V4.1 Flash experiment used 128 GB DDR5, a 5090 at 400 W and expert caching. The author reported 53.6 generation tokens/s with the 5090, rising to 63.5 when a 5060 Ti also computed experts. The faster figure is a two-GPU result. DeepSeek experiment This was custom experimental software, and the tested branch was not published at the time of the post. The author also reported that processing a million-token prompt took roughly 26 minutes. It demonstrates a possible configuration; it does not establish a ready-to-install everyday setup. DeepSeek experiment What requires troubleshooting or experimental software? Speculative decoding can help, but support matters Multi-token prediction, or MTP, proposes several tokens ahead and checks them against the main model. The collection reports a substantial speed increase for Qwen3.8-27B NVFP4 under vLLM 0.25.1 and for Gemma 4 31B with its draft head. The Flash-Next CPU-offload test showed a smaller, workload-dependent gain. At the time of those tests, some supplied heads were unsupported in llama.cpp. Benchmark collection Treat the model, checkpoint, draft head and runtime version as one configuration. A speedup measured with that combination does not automatically transfer to another engine or quantization. NVFP4 is a format, not a guarantee The same format name can cover checkpoints with different layers left at higher precision. The cited tests found meaningful differences between recipes. One FP4 setup report also required FlashInfer kernel compilation, ninja and a correctly configured CUDA toolkit; its findings apply to that tested environment. Benchmark collection The Level1Techs comparison ranked a cyankiwi AWQ checkpoint ahead of the tested NVFP4 alternatives on its fidelity measure. That is a result for those checkpoints and captured workflows, not proof that one format always wins. Quant-selection study A smaller KV cache buys capacity with qualifications The quant-selection study reports about 75% more KV-token capacity with FlashInfer/FP8 than with FA2/BF16, with a modest generation-speed improvement. However, its FP8 cache used uncalibrated scales, and its fidelity panel covered output through 50k context on an RTX PRO 6000 proxy. Performance and capacity were measured on the 5090. Those results do not establish equivalent quality across the full available context. Quant-selection study Driver and application failures need specific diagnoses NVIDIA’s driver documentation says Blackwell requires the open kernel modules, which depend on GSP firmware. Its repository guidance also states that the open modules cannot operate without GSP. Consequently, a blog’s suggestion to disable GSP should not be treated as a verified 5090 fix. NVIDIA documentation · NVIDIA repository answer Application reports need similar care: an open issue can contain a useful workaround, while a closed issue may only have been marked stale. The issue table below distinguishes those cases. Benchmark reference Reading the numbers: generation measures output speed; prompt processing measures input speed. They are separate measurements. tg128 is a 128-token generation benchmark; pp2048 processes a 2,048-token prompt. Neither alone describes a long interactive session. GB and GiB are retained as reported and are not interchangeable. A. Examples reported to run resident on one 5090 All rows below come from the same community benchmark collection using llama.cpp/CUDA. Sizes are checkpoint sizes, not total runtime memory. Generation is the short-context tg128 result; prompt processing is pp2048. Benchmark collection |Model and quantization|Checkpoint|Generation t/s|Prompt t/s|Test date| |:-|:-|:-|:-|:-| |Qwen3.6-27B · Q4_K_M|15.66 GiB|77.1|3,741|28 May 2026| |Qwen3.6-35B-A3B · UD-Q4_K_M|20.61 GiB|271.0|9,041|28 May 2026| |Qwen3-Coder-Next · UD-Q2_K_XL|24.92 GiB|224.9|4,421|28 May 2026| |Nemotron-3-Nano-30B-A3B · Q4_K_M|22.88 GiB|363.7|10,278|28 May 2026| |gpt-oss-20B · Q4_K_M|10.81 GiB|367.9|13,524|28 May 2026| |Gemma 4 12B · Q6_K|9.1 GiB|122.3|6,788|4 June 2026| |Gemma 4 31B · Q6_K|23.47 GiB|55.4|3,094|11 August 2026| |Gemma 4 31B · Q4_0|16.44 GiB|76.4|4,127|11 August 2026| These are historical baseline measurements. Their ordering is a throughput comparison of different models and quantizations, not a quality leaderboard. B. Larger models using system RAM |Model and configuration|Reported generation|Memory and runtime context|Evidence| |:-|:-|:-|:-| |Flash-Next · UD-Q2_K_XL|59.7 t/s; 51.0 at 32k|About 59 GB system RAM; llama.cpp b10853; --n-cpu-moe 22|8–9 September 2026 test| |gpt-oss-120B · MXFP4|46.5 t/s|About 30 GB VRAM; remaining weights in RAM; --n-cpu-moe 20|8 June report; 11 August dataset row report| |Mistral Small 4 · MXFP4|35.95 t/s|About 27.5 GB VRAM / 46 GB RAM; --n-cpu-moe 24|8 June report; 11 August dataset row report| |Ling-3.0-flash · IQ3_XXS|39.6 t/s|Routed experts in RAM; experimental llama.cpp branch|August 2026 test| |DeepSeek V4.1 Flash · UD-IQ1_S|53.6 t/s|128 GB host RAM; 5090 expert cache; experimental Basalt|October post; exact date unconfirmed report| |Same DeepSeek experiment, adding a 5060 Ti|63.5 t/s|Two GPUs; second card computes experts|Same author and experiment report| The host systems and methods differ. These rows establish reported feasibility; they cannot isolate which model or engine is inherently faster. C. A seven-engine Flash-Next experiment The Basalt developer compared seven configured engines using a 5090 at 400 W, 128 GB RAM and conversions of NVIDIA’s NVFP4 checkpoint. This table selects the 25k-context generation result from that experiment. Engine comparison |Engine|Generation t/s| |:-|:-| |Basalt|190| |Infernix|163| |capy-flash|152| |Strata|130| |ninfer-ext|92| |ninfer|53| |llama.cpp|37| Why this is not a universal engine ranking: there was one cold run per request; conversions and draft heads differed; llama.cpp ran without MTP and used FP16 KV, while the other configurations used INT8 KV. The author develops one of the engines. The results describe those complete setups. They do not isolate engine efficiency or establish equal output quality. Engine comparison D. Known issues and the status of reported fixes Statuses below reflect the reference check on 25 October 2026, not a guarantee about a later release. |Symptom|Affected report|What the source establishes| |:-|:-|:-| |Whole-GPU hangs in LM Studio|Qwen3.8-27B Q4_K_M; Windows 11; LM Studio 0.4.24+1|Issue open; reporter supplies a passing configuration issue| |Invalid CUDA kernel image|5090 D v2; Windows; Ollama 0.16.3|Open report; no confirmed fix established issue| |Slow Qwen3-VL inference|Ollama on a 5090|Open slowdown report; no confirmed fix established issue| |Inference crash through GPUStack|Qwen3.5-0.8B; vLLM 0.17.1|Fix verified in development; closed 25 May; shipped release not established issue| |Intermittent Q8_0 kernel crash|llama.cpp on sm_120|Reporter avoided it by removing Q8_0 weights; stale closure does not prove an upstream fix issue| |MTP plus vision causes OOM|Experimental llama.cpp MTP fork|Reporter confirmed a cherry-picked fix; closed 10 May; not established as 5090-specific issue| |OOM or insufficient cache blocks|Qwen models in vLLM|Closed after memory/quantization advice; successful retest not established issue| LM Studio configuration reported to pass: batch 8192, microbatch 128, context 32768, checkpoints 32, flash attention off, CUDA graphs off (GGML_CUDA_DISABLE_GRAPHS=1), full GPU/KV offload, one slot and MTP disabled. The report used CUDA12 runtime 2.40.0 and NVIDIA driver 616.92. This is a version-specific observation from one reporter. LM Studio issue Source notes and limitations This guide is an editorial synthesis of the reference check completed on 25 October 2026. Sources were inspected for agreement with the cited claims; the benchmarks were not independently rerun. Most numbers come from individual owners or engine developers. Official documentation is used for the NVIDIA driver requirements. Main sources |Source|Contribution|Principal limitation| |:-|:-|:-| |witcheer benchmark collection|Resident models, offload tests, MTP and quantization reports|One rig and harness; methods and dates vary across reports| |Detailed Mistral/gpt-oss report|Memory placement and throughput for two large models|Historical build and host configuration| |Seven-engine comparison|Flash-Next performance at several context depths|Engine-developer test; differing drafters, conversions and KV settings| |DeepSeek experiment|Expert caching, RAM limits and a second-GPU result|Tested branch unpublished at posting; exact date unconfirmed| |Level1Techs quant-selection study|Checkpoint fidelity and KV-cache tradeoffs|Workload-specific; parts of the quality analysis use a proxy GPU; dated 19 August 2026| |NVIDIA driver documentation and repository answer|Open-module and GSP requirements|Configuration guidance, not an inference benchmark| Issue reports are linked directly in the troubleshooting table. Their closure reasons are distinguished from evidence that a fix reached a released version. Material excluded from the main comparisons - Two Reddit references could not be retrieved: a purported Flash-Next optimization guide and a purported nine-model roundup. Their titles, dates and claims remain unverified; neither supports this guide’s conclusions. - An ambiguous gpt-oss result: the Hardware Corner article uses conflicting 20B and 120B labels around its large-context results. Its 112 t/s figure is excluded from the 120B comparison. The article also gives inconsistent 45k/47k limits for the dense 32B model. - A disputed driver fix: the GPU-loss blog is an account of symptoms and attempted workarounds. Its GSP-disable advice conflicts with NVIDIA’s open-module requirements, so it is not presented here as a supported fix. The evidence does not cover every model family, concurrent serving, laptop GPUs or comprehensive multi-GPU scaling. A successful short benchmark also leaves unanswered questions about sustained stability, long-context quality and performance on a different host. Companion document: full reference and audit. This guide selects the most useful material for readers; the companion retains the detailed research record. This report was compiled and written by AI using publicly available benchmarks, documentation and community reports. References were checked where accessible, and unresolved claims are identified. No benchmarks were run independently for this report; results are attributed to their original sources.

NVIDIA RTX 5060 is up on an M1 Max MacBook Pro, Linux, over USB4. NVIDIA's open driver had no case for the Mac's 16K memory pages, so setup failed. A 10-line fix got it running: Qwen3.8-27B fully on the card, 25 tps on CUDA. Fix sent to @nvidia: open-gpu-kernel-modules#1480

Modify and load custom VBIOS on Windows and Linux, on Blackwell 2.0 (RTX 50 Series)/Ada(RTX 40 Series)/Ampere (RTX 30 Series) without flashing (and which cards were tested) Hello guys, hoping you're doing fine. Today I want to share something that may affect your cards (? I have released 3 tools: 1. A way to modify VBIOSes, so you can increase power limit, voltage, NVVDD offsets, MSVDD offsets (Blackwell 2.0), OCPs, fan channels, power per fan, core offsets more than 1000, VRAM offsets more than 3000, lower power limits (below 400W on a RTX 5090), lower clocks, etc. But as you know, these can't be flashed directly on the cards because falcon, right? 2. A custom VBIOS loader on Windows, that patches the registry file related to that GPU, it resets it and it's applied on every reboot. This does not change the real VBIOS on your card, but it just loads a copy via a patch and it let you use any modification! 3. A custom VBIOS loader on Fedora, that patches the GSP firmware start on memory, builds a separate boot entry and then rebuilds automatically with kernel updates. This does not change the real VBIOS either. What are the requirements? - Windows: - Windows 10 or 11, 64-bit. - NVIDIA driver 616.56 or newer (status shows the version). - A payload file for that exact GPU model (same PCI device ID). - Linux: - A working NVIDIA 615.x driver or newer with the open kernel modules; nvidia-smi must list your GPUs. - The unpatched source of the open kernel modules for the exact installed version, for example: git clone --depth 1 --branch 615.78.08 https://github.com/NVIDIA/open-gpu-kernel-modules - Python 3.11 or newer, the headers for the running kernel (kernel-devel on Fedora), make, dracut, grub2-editenv and mokutil. With DNF5, also libdnf5-plugin-actions. - GRUB with GRUB_DEFAULT=saved and GRUB_ENABLE_BLSCFG=true (Fedora's defaults). - Secure Boot off, or your own module signing key: pass --signing-key and --signing-certificate to prepare. You need to first get a copy of your VBIOS, you can do it with GPU-Z on Windows, or with nvflash on Linux. Note that you can't modify EVERYTHING for the VBIOS, since it's still on research of what can be modified, what not and which rails are exposed. Also for example, VRAM timings can be modified (not on these tools) but they aren't applied, since the card reads it physically from the flash hardware. So, some example pics! First, some VBIOS editor example, for a RTX 5090 VBIOS, a RTX 4090 VBIOS, and a RTX 3090 VBIOS. RTX 5090 VBIOS Edit RTX 4090 VBIOS Edit RTX 3090 VBIOS Edit Then, the VBIOS loader on Windows looks like this: VBIOS loader, I have 4 gpus in this system Then you can choose a VBIOS, for example I will select a 671W VBIOS for the 4090. Choosing .bin file (for Ada and Ampere), for Blackwell you have to use the .rom file. Then if you see an OK on the left, you can press Load You get this warning, of something goes bad read the instructions, or DDU. And press OK/Accept, and a quick GPU restart after (no windows reboot), it works! Results, on Spanish UI (only English and Spanish for now) And it works just fine! PS C:\Users\User> nvidia-smi -i 0 -pl 671 Power limit for GPU 00000000:05:00.0 was set to 671.00 W from 550.00 W. All done. On the other hand for Linux, the UI looks very similar, and steps are similar, but you can also guide yourself on the github repo! You can edit the values you modified on MSI Afterburner, mvolt+ (recommended) on Windows. On Linux you can use LACT. Tested GPUs that I own, and it works: - RTX 6000 PRO MaxQ: Unlocked voltage (stock 0.9V) to 1.1V, power from 325W to 600W, core offset to be able to do +2000Mhz, VRAM to be able up to +6000Mhz (it depends of your luck), and some OCPs. - RTX 5090: PL from 600W to 800W, core offset to be able to do +2000Mhz, VRAM to be able up to +6000Mhz. - RTX 5080: PL from 360W to 500W, core offset to be able to do +2000Mhz, VRAM to be able up to +6000Mhz. - RTX 5070Ti: PL up to 450W, core offset to be able to do +2000Mhz, VRAM to be able up to +6000Mhz. - RTX 4000 PRO SFF: PL from 70W to 105W, core offset to be able to do +2000Mhz, VRAM to be able up to +7000Mhz, unlocked voltage from 0.85V to 1.1V. - RTX 5070: PL from 250 to 350W, core offset to be able to do +2000Mhz, VRAM to be able up to +6000Mhz. - RTX 5060Ti: PL from 185W to 300W, core offset to be able to do +2000Mhz, VRAM to be able up to +6000Mhz. - RTX 4090: PL up to 700W, core offset to be able to do +2000Mhz, VRAM to be able up to +6000Mhz. - RTX 2000 Ada: PL from 70W to 105W, unlocked voltage up to 1.1V. - RTX A2000 (Ampere): PL from 70W to 105W, unlocked voltage up to 1.1V. Tested GPUs that I don't own, by other users: - RTX 6000 PRO Workstation Edition - RTX 5090 - RTX 5080 Laptop - RTX 4070 - RTX 3060 For now, I can't seem to be able to edit Ada laptop variants (RTX 40 laptop series). Laptop Blackwell series (RTX 50 laptop series) can edit some parts of the VBIOS, but not all of them. Laptop Ampere series (RTX 30 laptop series) can edit almost everything. And finally, the links are: VBIOS Editor (Linux and Windows): Panchovix/nvidia-vbios-vix-editor Custom VBIOS loader (Windows): Panchovix/nvidia-windows-vbios-vix-loader Custom VBIOS loader (Linux): Panchovix/nvidia-linux-vbios-vix-loader Everything is open source, so you can check the code to see if there are applicable fixes and such. So if you guys can try, please let me know! If you find crashes on the vbios editor, or a specific GPU has info you can't edit and may be feasible to do so, you can raise an issue on github and I will check it out. Warning: You use these software entirely at your own risk. Any modification you make with it, anything derived from it or from its output, and any damage that results, is solely your responsibility. Then, the VBIOS loader on Windows looks like this:

Modify and load custom VBIOS on Windows and Linux, on Blackwell 2.0 (RTX 50 Series)/Ada(RTX 40 Series)/Ampere (RTX 30 Series) without flasing, for example to lower power limits (and which cards were tested) Hello guys, hoping you're doing fine. Today I want to share something that may affect your cards (? I have released 3 tools: 1. A way to modify VBIOSes, so you can increase power limit, voltage, NVVDD offsets, MSVDD offsets (Blackwell 2.0), OCPs, fan channels, power per fan, core offsets more than 1000, VRAM offsets more than 3000, lower power limits (below 400W on a RTX 5090), lower clocks, etc. But as you know, these can't be flashed directly on the cards because falcon, right? 2. A custom VBIOS loader on Windows, that patches the registry file related to that GPU, it resets it and it's applied on every reboot. This does not change the real VBIOS on your card, but it just loads a copy via a patch and it let you use any modification! 3. A custom VBIOS loader on Fedora, that patches the GSP firmware start on memory, builds a separate boot entry and then rebuilds automatically with kernel updates. This does not change the real VBIOS either. What are the requirements? - Windows: - Windows 10 or 11, 64-bit. - NVIDIA driver 616.56 or newer (status shows the version). - A payload file for that exact GPU model (same PCI device ID). - Linux: - A working NVIDIA 615.x driver or newer with the open kernel modules; nvidia-smi must list your GPUs. - The unpatched source of the open kernel modules for the exact installed version, for example: git clone --depth 1 --branch 615.78.08 https://github.com/NVIDIA/open-gpu-kernel-modules - Python 3.11 or newer, the headers for the running kernel (kernel-devel on Fedora), make, dracut, grub2-editenv and mokutil. With DNF5, also libdnf5-plugin-actions. - GRUB with GRUB_DEFAULT=saved and GRUB_ENABLE_BLSCFG=true (Fedora's defaults). - Secure Boot off, or your own module signing key: pass --signing-key and --signing-certificate to prepare. You need to first get a copy of your VBIOS, you can do it with GPU-Z on Windows, or with nvflash on Linux. Note that you can't modify EVERYTHING for the VBIOS, since it's still on research of what can be modified, what not and which rails are exposed. Also for example, VRAM timings can be modified (not on these tools) but they aren't applied, since the card reads it physically from the flash hardware. So, some example pics! First, some VBIOS editor example, for a RTX 5090 VBIOS, a RTX 4090 VBIOS, and a RTX 3090 VBIOS. RTX 5090 VBIOS Edit RTX 4090 VBIOS Edit RTX 3090 VBIOS Edit Then, the VBIOS loader on Windows looks like this: VBIOS loader, I have 4 gpus in this system Then you can choose a VBIOS, for example I will select a 671W VBIOS for the 4090. Choosing .bin file (for Ada and Ampere), for Blackwell you have to use the .rom file. Then if you see an OK on the left, you can press Load You get this warning, of something goes bad read the instructions, or DDU. And press OK/Accept, and a quick GPU restart after (no windows reboot), it works! Results, on Spanish UI (only English and Spanish for now) And it works just fine! PS C:\Users\User> nvidia-smi -i 0 -pl 671 Power limit for GPU 00000000:05:00.0 was set to 671.00 W from 550.00 W. All done. On the other hand for Linux, the UI looks very similar, and steps are similar, but you can also guide yourself on the github repo! You can edit the values you modified on MSI Afterburner, mvolt+ (recommended) on Windows. On Linux you can use LACT. Tested GPUs that I own, and it works: - RTX 6000 PRO MaxQ: Unlocked voltage (stock 0.9V) to 1.1V, power from 325W to 600W, core offset to be able to do +2000Mhz, VRAM to be able up to +6000Mhz (it depends of your luck), and some OCPs. - RTX 5090: PL from 600W to 800W, core offset to be able to do +2000Mhz, VRAM to be able up to +6000Mhz. - RTX 5080: PL from 360W to 500W, core offset to be able to do +2000Mhz, VRAM to be able up to +6000Mhz. - RTX 5070Ti: PL up to 450W, core offset to be able to do +2000Mhz, VRAM to be able up to +6000Mhz. - RTX 4000 PRO SFF: PL from 70W to 105W, core offset to be able to do +2000Mhz, VRAM to be able up to +7000Mhz, unlocked voltage from 0.85V to 1.1V. - RTX 5070: PL from 250 to 350W, core offset to be able to do +2000Mhz, VRAM to be able up to +6000Mhz. - RTX 5060Ti: PL from 185W to 300W, core offset to be able to do +2000Mhz, VRAM to be able up to +6000Mhz. - RTX 4090: PL up to 700W, core offset to be able to do +2000Mhz, VRAM to be able up to +6000Mhz. - RTX 2000 Ada: PL from 70W to 105W, unlocked voltage up to 1.1V. - RTX A2000 (Ampere): PL from 70W to 105W, unlocked voltage up to 1.1V. Tested GPUs that I don't own, by other users: - RTX 6000 PRO Workstation Edition - RTX 5090 - RTX 5080 Laptop - RTX 4070 - RTX 3060 For now, I can't seem to be able to edit Ada laptop variants (RTX 40 laptop series). Laptop Blackwell series (RTX 50 laptop series) can edit some parts of the VBIOS, but not all of them. Laptop Ampere series (RTX 30 laptop series) can edit almost everything. And finally, the links are: VBIOS Editor (Linux and Windows): Panchovix/nvidia-vbios-vix-editor Custom VBIOS loader (Windows): Panchovix/nvidia-windows-vbios-vix-loader Custom VBIOS loader (Linux): Panchovix/nvidia-linux-vbios-vix-loader Everything is open source, so you can check the code to see if there are applicable fixes and such. So if you guys can try, please let me know! If you find crashes on the vbios editor, or a specific GPU has info you can't edit and may be feasible to do so, you can raise an issue on github and I will check it out. Warning: You use these software entirely at your own risk. Any modification you make with it, anything derived from it or from its output, and any damage that results, is solely your responsibility.

Modify and load custom VBIOS on Windows and Linux, on Blackwell 2.0 (RTX 50 Series)/Ada(RTX 40 Series)/Ampere (RTX 30 Series) without flashing (and which cards were tested) Hello guys, hoping you're doing fine. Today I want to share something that may affect your cards (? I have released 3 tools: 1. A way to modify VBIOSes, so you can increase power limit, voltage, NVVDD offsets, MSVDD offsets (Blackwell 2.0), OCPs, fan channels, power per fan, core offsets more than 1000, VRAM offsets more than 3000, lower power limits (below 400W on a RTX 5090), lower clocks, etc. But as you know, these can't be flashed directly on the cards because falcon, right? 2. A custom VBIOS loader on Windows, that patches the registry file related to that GPU, it resets it and it's applied on every reboot. This does not change the real VBIOS on your card, but it just loads a copy via a patch and it let you use any modification! 3. A custom VBIOS loader on Fedora, that patches the GSP firmware start on memory, builds a separate boot entry and then rebuilds automatically with kernel updates. This does not change the real VBIOS either. What are the requirements? - Windows: - Windows 10 or 11, 64-bit. - NVIDIA driver 616.56 or newer (status shows the version). - A payload file for that exact GPU model (same PCI device ID). - Linux: - A working NVIDIA 615.x driver or newer with the open kernel modules; nvidia-smi must list your GPUs. - The unpatched source of the open kernel modules for the exact installed version, for example: git clone --depth 1 --branch 615.78.08 https://github.com/NVIDIA/open-gpu-kernel-modules - Python 3.11 or newer, the headers for the running kernel (kernel-devel on Fedora), make, dracut, grub2-editenv and mokutil. With DNF5, also libdnf5-plugin-actions. - GRUB with GRUB_DEFAULT=saved and GRUB_ENABLE_BLSCFG=true (Fedora's defaults). - Secure Boot off, or your own module signing key: pass --signing-key and --signing-certificate to prepare. You need to first get a copy of your VBIOS, you can do it with GPU-Z on Windows, or with nvflash on Linux. Note that you can't modify EVERYTHING for the VBIOS, since it's still on research of what can be modified, what not and which rails are exposed. Also for example, VRAM timings can be modified (not on these tools) but they aren't applied, since the card reads it physically from the flash hardware. So, some example pics! First, some VBIOS editor example, for a RTX 5090 VBIOS, a RTX 4090 VBIOS, and a RTX 3090 VBIOS. RTX 5090 VBIOS Edit RTX 4090 VBIOS Edit RTX 3090 VBIOS Edit Then, the VBIOS loader on Windows looks like this: VBIOS loader, I have 4 gpus in this system Then you can choose a VBIOS, for example I will select a 671W VBIOS for the 4090. Choosing .bin file (for Ada and Ampere), for Blackwell you have to use the .rom file. Then if you see an OK on the left, you can press Load You get this warning, of something goes bad read the instructions, or DDU. And press OK/Accept, and a quick GPU restart after (no windows reboot), it works! Results, on Spanish UI (only English and Spanish for now) And it works just fine! PS C:\Users\User> nvidia-smi -i 0 -pl 671 Power limit for GPU 00000000:05:00.0 was set to 671.00 W from 550.00 W. All done. On the other hand for Linux, the UI looks very similar, and steps are similar, but you can also guide yourself on the github repo! You can edit the values you modified on MSI Afterburner, mvolt+ (recommended) on Windows. On Linux you can use LACT. Tested GPUs that I own, and it works: - RTX 6000 PRO MaxQ: Unlocked voltage (stock 0.9V) to 1.1V, power from 325W to 600W, core offset to be able to do +2000Mhz, VRAM to be able up to +6000Mhz (it depends of your luck), and some OCPs. - RTX 5090: PL from 600W to 800W, core offset to be able to do +2000Mhz, VRAM to be able up to +6000Mhz. - RTX 5080: PL from 360W to 500W, core offset to be able to do +2000Mhz, VRAM to be able up to +6000Mhz. - RTX 5070Ti: PL up to 450W, core offset to be able to do +2000Mhz, VRAM to be able up to +6000Mhz. - RTX 4000 PRO SFF: PL from 70W to 105W, core offset to be able to do +2000Mhz, VRAM to be able up to +7000Mhz, unlocked voltage from 0.85V to 1.1V. - RTX 5070: PL from 250 to 350W, core offset to be able to do +2000Mhz, VRAM to be able up to +6000Mhz. - RTX 5060Ti: PL from 185W to 300W, core offset to be able to do +2000Mhz, VRAM to be able up to +6000Mhz. - RTX 4090: PL up to 700W, core offset to be able to do +2000Mhz, VRAM to be able up to +6000Mhz. - RTX 2000 Ada: PL from 70W to 105W, unlocked voltage up to 1.1V. - RTX A2000 (Ampere): PL from 70W to 105W, unlocked voltage up to 1.1V. Tested GPUs that I don't own, by other users: - RTX 6000 PRO Workstation Edition - RTX 5090 - RTX 5080 Laptop - RTX 4070 - RTX 3060 For now, I can't seem to be able to edit Ada laptop variants (RTX 40 laptop series). Laptop Blackwell series (RTX 50 laptop series) can edit some parts of the VBIOS, but not all of them. Laptop Ampere series (RTX 30 laptop series) can edit almost everything. And finally, the links are: VBIOS Editor (Linux and Windows): Panchovix/nvidia-vbios-vix-editor Custom VBIOS loader (Windows): Panchovix/nvidia-windows-vbios-vix-loader Custom VBIOS loader (Linux): Panchovix/nvidia-linux-vbios-vix-loader Everything is open source, so you can check the code to see if there are applicable fixes and such. So if you guys can try, please let me know! If you find crashes on the vbios editor, or a specific GPU has info you can't edit and may be feasible to do so, you can raise an issue on github and I will check it out. Warning: You use these software entirely at your own risk. Any modification you make with it, anything derived from it or from its output, and any damage that results, is solely your responsibility.

@VZ24022004 Is the crash an "Xid 109 CTX SWITCH TIMEOUT"? If so, the following issue might be helpful: open-gpu-kernel-modules#1409

open-gpu-kernel-modules#1075 진짜 돌아버리겠네... egpu 유저들 대체 어떤 싸움을 해오신겁니까