Start with the call that fails. Chromium's ANGLE backend asks the EGL or Vulkan loader for a device, and the loader answers out of the ICD registration files a driver installs; inside the MIG pod that Vulkan list was empty, according to the developer's account on dev.to [6][17]. With nothing to enumerate, ANGLE does the thing it is built to do and falls back to SwiftShader, its CPU rasteriser [3][6]. No error surfaces. The pod schedules, nvidia-smi prints the H100 and its MIG devices, and the frame counter is the only place the fault appears [5].
So the Chromium flags were never the variable. `--use-gl=angle` with egl and with vulkan produced the same fallback [6], because NVIDIA's spec puts graphics APIs outside MIG entirely: the partitions are compute-only, and the largest 7g.80gb profile draws exactly as many frames as the smallest [7]. A scheduler that can place the pod tells you nothing about whether a driver can draw.
Disabling MIG and taking the whole card is the theoretical fix, and it is worth reading what that buys. The H100 keeps only 2 graphics TPCs and has no NVENC [8], so H.264 encoding lands back on the CPU regardless. The developer also could not drain the slices, which were carrying LLM and speech inference at the time [9].
The 4fps figure is a claim about one scene on one rented CPU allocation, and the writeup does not name the CPU [3]. What transfers is the invariance. Frame rate did not move across 720p, 540p and 360p [4]; on the usual reading of those labels that is roughly a fourfold cut in pixels for no gain [16], which locates the cost in per-frame scene work such as skinning and draw setup rather than in fill. Plain WebGL held 60fps on the same software path [3]. If your scene is a couple of textured quads, SwiftShader may well be adequate. If it is a skinned character under a toon shader, the fallback plan of 540p at 24fps is already six times faster than what you actually have [15].
The second way to lose is quieter, because it produces the same log line on hardware that is fine. NVIDIA's container capability variable excludes graphics libraries by default, so a rendering-capable GPU handed to a container without `NVIDIA_DRIVER_CAPABILITIES=all` presents an empty ICD too [12]. That makes the acceptance test identical in both cases: `eglinfo` listing NVIDIA EGL devices, a non-empty `icd.d`, libglvnd present [12]. That test belongs before the instance is signed for, since CUDA core counts and VRAM in the catalogue do not expose any of it [10], and the writeup's own conclusion is to keep compute and rendering GPUs on separate books [13].
