GPU Passthrough and Hardware Transcoding

First Services flagged that software transcoding - the CPU converting video on the fly for a device that can't play the source format natively - gets expensive fast: a modest CPU manages one 1080p stream, and 4K or multiple simultaneous streams want real help. That help is a GPU, and getting one usable by Jellyfin (or Immich's machine learning, or anything else that benefits) inside Proxmox means picking between two genuinely different approaches.

Two different problems, not one

• Sharing an iGPU (the graphics built into most Intel/AMD desktop and laptop CPUs) across multiple guests - the common case, and what almost everyone reading this actually wants for Jellyfin.
• Dedicating a discrete GPU entirely to one VM (full PCIe passthrough) - for workloads that need exclusive access to a real GPU: a Windows gaming VM, GPU-accelerated ML/AI work, or Nvidia NVENC encoding at a scale an iGPU can't match. Only one guest can use the card at a time, and the Proxmox host loses access to it entirely while a VM holds it.

Start with the first one. It's simpler, it's what an iGPU is good at, and it's very likely the only piece of this page you actually need.

Sharing an iGPU into an LXC container

Since an LXC container shares the Proxmox host's kernel (unlike a VM), giving it access to the host's GPU device nodes is a device bind-mount, not a passthrough in the PCIe sense - much simpler, and the host and any number of other LXC guests can use the same iGPU concurrently.

On the Proxmox host, confirm the device nodes exist:

ls -l /dev/dri

You should see renderD128 (and usually card0). In the LXC container's config (Proxmox host shell, editing /etc/pve/lxc/<vmid>.conf, or via the GUI's Resources > Add > Device Passthrough on newer Proxmox versions):

lxc.cgroup2.devices.allow: c 226:0 rwm
lxc.cgroup2.devices.allow: c 226:128 rwm
lxc.mount.entry: /dev/dri/renderD128 dev/dri/renderD128 none bind,optional,create=file

If you're running Docker inside that LXC container (the pattern from Proxmox VMs and Containers), this is the first of two layers - the LXC container now has /dev/dri available, but Jellyfin's own container still needs it passed through a second time in its compose file:

services:
  jellyfin:
    image: jellyfin/jellyfin:latest
    container_name: jellyfin
    devices:
      - /dev/dri:/dev/dri
    ports:
      - "8096:8096"
    volumes:
      - ./config:/config
      - ./cache:/cache
      - /path/to/your/media:/media
    restart: unless-stopped

Finally, in Jellyfin's own admin dashboard (Playback), enable hardware acceleration and select Intel QuickSync (QSV) (or VAAPI on some AMD/older Intel setups) as the transcoding method. Without this last step, the device is available but unused - Jellyfin still defaults to software transcoding until you tell it otherwise.

Resource expectations: dramatically lighter than software transcoding - a mid-range Intel iGPU with QuickSync handles several simultaneous 4K-to-1080p transcodes at a CPU cost that's barely measurable, versus one struggling software-transcoded stream on the same machine.

Full PCIe passthrough to a VM

For a dedicated discrete GPU handed entirely to one VM, the process is heavier and host-wide, not per-guest:

1. Enable IOMMU in BIOS/UEFI (often labeled Intel VT-d or AMD-Vi).
2. Add intel_iommu=on (or amd_iommu=on) to the Proxmox host's kernel boot parameters and regenerate the bootloader config.
3. Blacklist the GPU's driver on the host so Proxmox itself never binds to it, leaving it free to hand to a guest.
4. Add the device to the VM's hardware config as a PCI Device, with All Functions and PCI-Express checked.

⚠️ Risk: while a VM holds a passed-through GPU, it's completely unavailable to the Proxmox host and every other guest - there's no sharing at this level, unlike the LXC/iGPU approach above. Consumer Nvidia cards have also historically thrown a driver error ("Code 43") inside Windows VMs unless the VM config spoofs vendor IDs to hide that it's virtualized - a well-documented but genuinely fiddly workaround, and one more reason to reach for this only when the iGPU/LXC approach genuinely doesn't cover what you need.

Most homelab mini PCs (the common Beginner-tier hardware) don't have a discrete GPU to passthrough at all - if that's you, the iGPU/LXC path above is the entire relevant section of this page, not a stepping stone to the rest of it.

Next: Home Assistant.