The P102-100 is a GP102-based card (GTX 1080 Ti) marketed specifically for mining. While the silicon is identical to the consumer flagship, it lacks video outputs and has the NVENC/NVDEC blocks disabled at the driver level. On Windows, there are known workarounds involving registry edits and driver version matching, but the Linux driver architecture presents a much more significant barrier due to the proprietary nature of the NVIDIA Resource Manager (RM).
The PCI Identity Spoof
The NVIDIA Linux driver consists of an open-source kernel shim (nvidia.ko) and a pre-compiled, closed-source binary object named nv-kernel.o_binary. The shim handles the initial PCI probing.
I modified nvidia/nv-pci.c within the 580.95.05 driver source to intercept the probe and force the kernel’s PCI device structure to mirror a GTX 1080 Ti (Device ID 1B81) instead of the P102-100 (Device ID 1B82).
/* Modification in nvidia/nv-pci.c */
if (pci_dev->device == 0x1b82) {
*(volatile u16 *)(&pci_dev->device) = 0x1b81;
pci_dev->class = 0x030000; // Change from 3D Controller to VGA Controller
*(volatile u8 *)(&pci_dev->revision) = 0xa1;
nv_printf(NV_DBG_ERRORS, “NVRM: Injected 1080 Ti Device ID and Class 0x0300.\n”);
}
- MMIO Verification via Envytools
After compiling and loading the modified module, nvidia-smi successfully identified the hardware as a GeForce GTX 1080 Ti. To verify if the MMIO registers for the encoder were accessible, I used nvapeek from the envytools suite.
Prior to the identity spoof, the memory range for the encoder returned badf1100 (register unmapped). After the spoof, reading the 0x1c0000 range (NVENC) returned actual data:
Bash
Reading the NVENC register space
root@dnlserver:~# ./nvapeek 0 0x1c0000
00000200: 40003120 0000000f 206cd0cc …
The value 40003120 at offset 0x200 corresponds to the Master Control register. This indicates that the engine is powered and receiving a clock signal. The hardware is electronically active and mapped into the system memory space.
3. The Obstacle: nv-kernel.o_binary
Despite the kernel shim reporting a consumer ID, the driver’s core logic remains inside nv-kernel.o_binary. This is an ELF object file provided by NVIDIA without source code. When an application (like FFmpeg) attempts to initialize an NVENC session, the call passes through the open-source shim into the proprietary blob.
The blob appears to perform secondary verification. Since it is pre-compiled machine code, we cannot modify its internal logic to ignore the hardware-level identifiers (likely pulled via the GSP firmware or internal ROM) that distinguish a P102-100 from a 1080 Ti. Even with a patched blob that removes session limits, the “Reset Release” command for the NVENC block is never issued if the internal check fails.
Result - A brick wall
The lockout is enforced at the link stage between the open-source shim and the proprietary binary. While we can successfully forge the device identity and class within the Linux kernel’s PCI subsystem to map the engine’s MMIO space, the proprietary object file acts as a final gatekeeper for engine initialization. Unless the nv-kernel.o_binary itself is successfully reverse-engineered to bypass these internal ID checks, the encoder on these cards remains inaccessible under Linux.