Most home media servers I have set up in the last decade spent a discrete GPU doing the kind of work the chip on the CPU die was already capable of doing. The reason is habit more than hardware. We learned the rules back when Linux driver support was rough, and the safe play was always a real graphics card with PCIe passthrough. Those rules are mostly outdated now, and the hardware has caught up. The dedicated GPU sitting in your media server is, more often than not, a 180-watt part doing a job the iGPU on your CPU could handle for a few watts and almost no heat.
The cheap way to find out whether this applies to you is to check what your CPU actually has. Almost any iGPU sold in the last decade ships with a hardware video encoder and decoder sitting idle on the die. These are dedicated silicon built for one job, which is moving compressed video between formats, and they do it using a fraction of the power a real card pulls. For most home media libraries, that is plenty of machine.
What the iGPU actually does and does not
The thing that catches people off is how much of a media server is video work and how little of it is general compute. Transcoding (converting a video stream from one codec, or compression format, to another on the fly because the device playing it cannot decode the original) is the bottleneck for almost every home media setup. The iGPU handles that work in hardware, leaving the CPU almost idle. A 1080p stream finishes with single-digit CPU usage. Multiple streams at once stay smooth. 4K H.265 streams climb into the 40 to 60 percent range but stay watchable. The setup is fast, the heat is minimal, the power draw is a fraction of a discrete GPU, and the cost is so low that the only reason not to do it is that you already have a GPU you are not using.
HDR tone mapping is the one workload where generations matter. Tone mapping is the work of converting HDR video into something an SDR screen can display without losing detail in the highlights or shadows, and it is the part of media serving that benefits most from a real GPU. A modern N100 generation iGPU handles SDR tone mapping fine. The HDR case is where it starts to fall short, especially on the more demanding HDR formats that newer displays can show. For everyone running a homelab media server, that distinction is the entire decision.
The pattern here is that the iGPU handles every codec your library probably contains, with a single edge case where it falls short. The edge case is real, but it is not most of your library.
Why homelab guides still recommend a discrete GPU
If you have read any homelab guide written before 2024, it almost certainly recommends passing a discrete GPU through to your media container. That recommendation made sense when it was written. Linux driver support for iGPU hardware acceleration was uneven, the only reliable path was Nvidia with proprietary drivers, and the safest setup was the one everyone had already debugged. The hardware has caught up since then. The Linux kernel ships first-class drivers for Intel and AMD iGPUs. The major media server applications all detect and use them with no extra configuration beyond turning the setting on.
The recommendation persists for a different reason, which is that the people writing guides are still working from the old rules. They are not wrong to flag the edge cases. They are wrong to present the edge cases as the default case. For a library of mostly 1080p H.264 and H.265 files (which describes most home media collections), the iGPU on a $50 N100 board is honest overkill for the job. The cost is so low that the only reason not to do it is that you already have a GPU you are not using.
How to check whether your CPU has the hardware you need
The check is short and worth doing once. Look at the host your media container runs on and see whether the iGPU is exposed to the operating system. Make sure the device shows up where your container runtime can pass it through. If it does, you have what you need.
In the media server’s web UI, dig into the transcoding section and look for the hardware acceleration option. Pick the vendor dropdown that matches your iGPU (Intel, AMD, or Nvidia on the rare board that has one). Save the setting, then bounce the container so it re-reads the device tree at startup. That container restart is the part most people forget. After it restarts, queue up a file your client cannot play natively and watch the activity panel. The hardware row should fill up while the CPU row stays quiet. If the dashboard shows software transcoding instead, the usual culprit is permissions on the render and video nodes. Drop your media user into both groups, bounce the container again, and retest.
A more thorough check is to push the workload. Play four or five transcoded streams at once and watch what the load looks like. If the iGPU is doing the work, CPU usage should stay low and the streams should remain smooth. If CPU usage climbs into the 80+ percent range, something is wrong with the configuration, not with the iGPU. The hardware will handle the load. The setup is what determines whether the hardware gets used.
A few practical signals worth knowing:
- The hardware row lights up and the CPU row stays flat on the same transcode. Hardware acceleration is on.
- The hardware row is silent but the transcode still completes. You are falling back to software. Check permissions and restart.
- The hardware row is active and CPU is also climbing into the 40+ range. Your iGPU generation is hitting the edge of what it can do for 4K HDR. Consider a different workload split.
- The hardware row never appears at all. The iGPU is not visible to the container. Check device passthrough before anything else.
Where the iGPU is still the wrong call
There is one category of work where the iGPU does not earn its slot, and that is HDR tone mapping for high quality local files where you want the best possible picture. Tone mapping is the work of converting HDR video into something an SDR screen can display without losing detail in the highlights or shadows, and it is the part of media serving that benefits most from a real GPU. The N100 generation of hardware encoders handles SDR tone mapping fine. The HDR case is where it starts to fall short, especially on the more demanding HDR formats that newer displays can show.
For everything else, the iGPU is honest. 1080p streams, 4K H.264 and H.265 streams, audio transcoding, multiple streams at once, all of it is well within the iGPU’s range. The few edge cases where a modern discrete GPU earns its slot are the workloads that benefit from hardware-accelerated HDR pipeline, which is a smaller slice of home media serving than most guides imply. Most people running a homelab media server will never notice the gap. The people who will notice are the ones with HDR-capable displays and high-bitrate local rips, and they are a small slice.
Trade-offs
The honest cost of moving to iGPU-only transcoding is that you give up some headroom on the workloads you may never actually run. The benefit is that you free up a PCIe slot, drop your power draw, shrink your heat output, and free the GPU you were using for whatever else you wanted to use it for. For most homelabs, that benefit is large and the cost is small. For homelabs running HDR displays with high-bitrate local rips, the math is different and a real GPU still earns its slot.
There is also a small cost in setup time. The first time you configure hardware acceleration in the media server, you will probably spend an hour on permissions, device passthrough, and container configuration. After that, it works. The migration cost is real but bounded. The power and heat savings are ongoing. The PCIe slot you free up is whatever you make of it.
The path most people should take is the cheap one. Try the iGPU first. Run your normal workload on it for a week. If you do not notice the missing GPU, do not put it back. If you do notice it, the GPU is still sitting in your parts bin and the move back is a five-minute configuration change. The downside of trying is small. The upside of sticking with it is real and ongoing, and it is the kind of win most homelabs should take.