keylase/nvidia-patch: Removing the NVENC session limit on consumer Nvidia GPUs

What the NVENC session cap costs you

Nvidia limits how many simultaneous NVENC video encoding sessions a consumer-grade GPU will run. The README states the NVENC patch "removes restriction on maximum number of simultaneous NVENC video encoding sessions imposed by Nvidia to consumer-grade GPUs." If you run a media server, a game-streaming setup, or any workload that opens several encoder sessions at once on a GeForce card, that ceiling decides how many streams you can serve from one machine. The same repository also ships an NvFBC patch, described as allowing NvFBC on consumer-grade GPUs, which matters for capture workflows that the consumer driver otherwise refuses. The intended audience is the self-hosting and Linux desktop crowd: people with a consumer card who want datacenter-style encoder concurrency without buying datacenter hardware. The project is explicit that GNU/Linux is the main target, with a separate win directory for Windows.

How the patch works and which driver versions it covers

The mechanism is a binary patch applied to the installed Nvidia driver library, not a kernel module or a wrapper around the encoder API. The README says the patch should be applied in the same way for NvFBC as for NVENC, using patch-fbc.sh instead of patch.sh. Coverage is the central constraint: the README carries a version table where each driver release is marked YES or NO for the NVENC patch and for the NVFBC patch. Older rows such as 375.39 and 390.77 show YES for NVENC and NO for NvFBC, while 440.26 is the first row in the visible table where both columns read YES. The badge at the top of the README names 615.71.09 as the latest Linux driver version. That table is the actual compatibility contract. A driver release that is not in it has no patch entry, and the README does not describe a fallback for unlisted versions. The repository layout also includes drivers.json and a tools directory, which suggests the table is generated from structured data rather than maintained by hand, though the README does not document that pipeline.

Requirements before you patch anything

The README lists four requirements: x86_64 system architecture, a GNU/Linux operating system, an NVENC-compatible GPU, and an Nvidia driver whose version appears in the version table. The architecture line is stricter than it first looks. On ARM or any non-x86_64 host, the project does not claim support. The GPU must appear on Nvidia's video encode and decode support matrix, which the README links. If your card is not on that matrix, the patch is the wrong tool regardless of driver version. There is no stated requirement for a specific distribution, kernel, or CUDA toolkit, and the README does not mention Secure Boot, DKMS, or how the patch interacts with driver updates. That silence is worth noting: nothing in the README tells you what happens to the patched library after the next driver installation.

Running patch.sh, patch-fbc.sh and the Dockerfile

The README does not print a copy-paste install sequence. What it does give is the entry points: patch.sh for the NVENC patch and patch-fbc.sh for NvFBC, applied the same way. The Dockerfile shows the container path and what it copies into the image.

FROM nvidia/cuda:latest

ENV NVIDIA_VISIBLE_DEVICES all
ENV NVIDIA_DRIVER_CAPABILITIES compute,video,utility

RUN mkdir -p /usr/local/bin /patched-lib
COPY patch.sh docker-entrypoint.sh /usr/local/bin/
RUN chmod +x /usr/local/bin/patch.sh /usr/local/bin/docker-entrypoint.sh

ENTRYPOINT ["/usr/local/bin/docker-entrypoint.sh"]

That file is the clearest statement of how the project is meant to be invoked: patch.sh and docker-entrypoint.sh land in /usr/local/bin, both are made executable, and docker-entrypoint.sh becomes the entrypoint. The environment variables it sets are NVIDIA_VISIBLE_DEVICES to all and NVIDIA_DRIVER_CAPABILITIES to compute,video,utility. The RUN line also creates /patched-lib, which is not explained in the README. For NvFBC instead of NVENC, the README says to use patch-fbc.sh in place of patch.sh. The visible table shows NvFBC support starting later than NVENC support, so check the NVFBC column for your driver version before you run it.

Where this patch breaks or is the wrong choice

The version table is the failure mode. Driver releases outside it are not covered, and Nvidia ships new drivers regularly, so a fresh install can leave you unpatched until the table catches up. The README does not document rollback, does not say whether the patch modifies the library in place or writes a copy, and does not describe how to restore the original file. The Dockerfile creates a /patched-lib directory, which hints at a copy-based flow, but the README itself does not explain it. If you cannot identify your original library, restoring it after a failed patch is guesswork. The patch is also wrong for anyone on Windows who expects patch.sh to work: the README directs Windows users to the win directory instead. Non-x86_64 hosts are out of scope. And if your GPU is not on Nvidia's encoder support matrix, no patch version will help. Finally, this is a modification of a proprietary driver component, which is a support and licensing question rather than a purely technical one.

How it compares with a datacenter card or a re-encode pipeline

The direct alternative is buying a card whose driver does not impose the consumer session limit, such as an Nvidia datacenter part. That path costs more hardware but needs no patching, survives driver upgrades, and stays inside Nvidia's supported configuration. The other alternative is to change the workload instead of the driver: decode once and encode a single stream, or transcode in software with FFmpeg, so you never open more concurrent NVENC sessions than the stock limit allows. Software encoding moves the bottleneck to CPU and changes power draw and quality-per-bit, but it removes the dependency on a driver-version table entirely. The patch sits between those two: it keeps your existing consumer card and your existing pipeline, at the cost of re-checking compatibility every time the driver moves. That is a real trade, and it is the reason the version table matters more than any feature list here.

Maintenance, upgrades and licence status

The repository is not archived, and the last push was on 2026-09-15, so the project is current as of that date. The version table is the maintenance surface you inherit: every new Nvidia driver release needs a matching entry before you can upgrade safely, and the top of the README tracks the latest Linux driver version. Practically, that means pinning your driver to a version the table marks YES, or waiting after each upgrade until the table is updated. The README does not describe an upgrade procedure for the patch itself, so treat a driver upgrade as a re-patch event and verify the new version is listed first. On licensing, the repository metadata does not state a licence, and the README does not discuss one. The patch modifies a proprietary Nvidia driver library, so the terms that apply to that library are worth reading before you redistribute a patched image. This is not legal advice; the README simply does not address the question.

Editorial conclusion

Adopt it if you run GNU/Linux on x86_64 with a consumer Nvidia card and you need more than the stock number of simultaneous NVENC sessions, and if your exact driver version appears in the README version table with NVENC patch YES. Do not adopt it on Windows through patch.sh, on non-x86_64 systems, or on a driver version the table does not list. Before patching, confirm the driver version, check the table row for that version, and keep the original library so you can restore it after a driver upgrade.

Frequently asked questions

Official sources

1. Issues
2. keylase/nvidia-patch on GitHub
3. README