An H100's MIG slices hand Chromium's WebGL straight back to the CPU rasteriser
NVIDIA documents MIG as compute-only, so headless Chromium inside an H100 slice opens no GPU context at all and quietly falls back to CPU rasterising, which surfaces as a frame rate problem rather than a missing driver.
The Engineer · Build desk
What happened
- A developer building a 24/7 AI avatar stream needed headless Chromium to render WebGL on a GPU before ffmpeg encoded H.264 and AAC for an RTMP push to the platform.
- Borrowing a spare 1g.10gb MIG slice scheduled cleanly and nvidia-smi listed the H100 inside the Pod, yet Chromium still fell back to SwiftShader and the Vulkan ICD registration was empty.
- NVIDIA's spec makes MIG compute-only with no graphics API support, so even the largest 7g.80gb profile cannot render a frame on the GPU.
- The renderer ended up on an RTX 4000 Ada or RTX 2000 Ada at $0.24 to $0.28 an hour, which handled 720p30 without strain.
Why it matters
- What it limits constraint Capacity planning cannot reach this failure, because no stack of slices adds a graphics API, so the usual lever of requesting a bigger allocation is dead on arrival.
- Who has to decide decision The procurement question moves from VRAM and CUDA cores to whether the SKU exposes EGL and Vulkan, which stops compute and rendering GPUs being one fungible pool.
- What it costs cost Continuous rendering on the cheap Ada card runs about $173 to $202 a month, and that bill sits with whoever owns the stream rather than with the inference cluster.
- Who's exposed exposure Teams sharing an inference cluster with a render job inherit a fault their dashboards report as a low frame rate, which sends debugging effort at performance instead of at a hidden driver.
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 [7][13]. With nothing to enumerate, ANGLE does the thing it is built to do and falls back to SwiftShader, its CPU rasteriser [4][7]. 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 [6].
So the Chromium flags were never the variable. `--use-gl=angle` with egl and with vulkan produced the same fallback [7], 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 [1]. 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 [17], 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 [8].
The 4fps figure is a claim about one scene on one rented CPU allocation, and the writeup does not name the CPU [4]. What transfers is the invariance. Frame rate did not move across 720p, 540p and 360p [5]; 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 [4]. 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 [11]. That makes the acceptance test identical in both cases: `eglinfo` listing NVIDIA EGL devices, a non-empty `icd.d`, libglvnd present [11]. That test belongs before the instance is signed for, since CUDA core counts and VRAM in the catalogue do not expose any of it [9], and the writeup's own conclusion is to keep compute and rendering GPUs on separate books [12].
What to watch
- Whether cloud GPU catalogues start listing graphics API support beside CUDA cores and VRAM.
- Whether a future NVIDIA driver or MIG profile exposes graphics APIs inside a slice.
- Whether container runtimes warn when a GPU is allocated but no EGL or Vulkan ICD is visible inside the namespace.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence62
- Adoption26
- Hype gap−8
- Incentives18
- Confidence55
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
Per NVIDIA's official spec, MIG is compute-only and does not support graphics APIs; this is a functionality issue rather than a performance one, so no amount of stacked slices, even the largest 7g.80gb, will render a single frame on the GPU.
- [2]
"You need a GPU" covers two distinct scenarios: compute (training and inference, where working CUDA is sufficient) and rendering (3D rendering, gaming, video production, which requires OpenGL, Vulkan or EGL). Some models within NVIDIA's lineup can only handle one of the two.
- [3]
The workload was an unmanned AI avatar streaming system: headless Chromium rendering a 3D avatar with WebGL, screen and audio capture, encoding to H.264 plus AAC with ffmpeg, then streaming to the platform over RTMP, running 24/7.
- [4]
Chromium's SwiftShader is a CPU-based WebGL backend, so WebGL works without a GPU; plain WebGL ran at 60fps, but the 3D avatar scene using a toon shader and skinning managed only about 4fps.
- [5]
Frame rate stayed at about 4fps at 720p, 540p and 360p, so the bottleneck was scene processing rather than pixel processing, and the planned fallback of 540p at 24fps was useless from the start.
- [6]
The cluster's H100 was divided into 1g.10gb MIG slices for LLM and speech inference; a renderer test Pod scheduled successfully on a free slice and nvidia-smi inside the Pod showed the H100 and MIG devices, but Chromium's WebGL still fell back to SwiftShader.
- [7]
No Chromium flag configuration changed the outcome, including --use-gl=angle with egl or with vulkan, and a check of Vulkan's ICD driver registration information showed it was empty.
- [8]
Disabling MIG to use the entire H100 would in theory enable graphics APIs, but was operationally impossible while all slices were in use by inference services.
- [9]
Catalog specifications such as CUDA cores and VRAM do not reveal whether a GPU can render.
- [10]
The renderer was moved to a rendering-capable cloud GPU; for rendering the author recommends graphics-designed GPUs such as L4, T4 or RTX series, and an RTX 4000 Ada or RTX 2000 Ada at $0.24 to $0.28 per hour easily handled 720p30.
- [11]
Having a GPU allocated does not mean graphics drivers are accessible: container settings can hide them. Checks listed are setting NVIDIA_DRIVER_CAPABILITIES=all because the default excludes graphics libraries, presence of an EGL ICD (10_nvidia.json equivalent) verified with eglinfo, a non-empty Vulkan icd.d, and libglvnd installed.
- [12]
Treating compute GPUs and rendering GPUs as separate inventories was the author's biggest design change.
- [13]
The account is a dev.to post by orca_forge, originally published in Japanese at forge.workstyle.tech, based on actual measurements using rented cloud GPUs.
- [14]
At $0.24 to $0.28 per hour, running the rendering GPU continuously for a 30-day month costs about $172.80 to $201.60.
- [15]
The 24fps fallback target was six times the roughly 4fps that the CPU rasteriser delivered.
- [16]
Dropping from 720p to 360p is about a fourfold reduction in pixels per frame, assuming the conventional readings 1280x720 and 640x360, and it produced no frame rate change.
- [17]
The H100 has only 2 graphics TPCs, its architecture stripped of rendering units for AI compute, and no NVENC hardware encoder, so even with graphics APIs working, rendering performance would be poor and streaming would lack H.264 hardware encoding.
Get this ledger inside ChatGPT. Ask about any of our stories and the answer brings its figure, each claim’s verdict and the sources. Free, no account.
Sources
1 independent publisher whose own reporting we read for this story.
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.