OpenGL invalid value error in depth viewers: fix the GPU driver

The viewer opens, the depth stream counts frames, you switch to the 3D view — and the window dies with GL_INVALID_VALUE, quoting a line of the viewer's own OpenGL helper code. The reflex is to reinstall the camera SDK, swap the USB cable, try another port. Stop there: frames are arriving, so the camera, the cable and the capture path are already proven. This error comes from the graphics driver on the viewing PC, and in practice it means the driver is serving an OpenGL context too old or too generic to run the point-cloud render. This page ranks the causes in the order they occur on Windows, gives a test for each, puts the fixes in order with the arithmetic that rules out the expensive wrong turns, and ends with the decision for every case.

What GL_INVALID_VALUE is telling you

An OpenGL error code is the driver refusing a call instead of drawing. The OpenGL specification defines GL_INVALID_VALUE as generated when a value parameter is not a legal value for that function. In a depth viewer, the call that fails is one the 3D view cannot live without: a shader program, a vertex buffer for the cloud, a texture for the depth map. A current driver rejects only genuinely illegal values; an old or generic driver also rejects perfectly legal OpenGL 3 calls, because the context it hands out predates them.

That is why the same viewer runs on one PC and dies on the next — the code did not change, the driver did. The file path and line number in the crash text point into the viewer's renderer, not at your data. Chase the driver, not the point cloud.

Prove the camera is innocent first

Two minutes of evidence saves an afternoon of blind reinstalling.

• Frames still count. Capture, recording and export keep working while the 3D view is broken, so the sensor and its link are healthy.
• The same camera renders on another PC. Any laptop with a current graphics driver will do; if the cloud draws there, the fault is pinned to the first machine's graphics stack.
• Only the draw path fails. Depth values, confidence and colour all arrive — it is the OpenGL presentation that dies.

The camera in this story — one of the 3D sensors on the bench, a laser profiler or a stereo depth camera — has done its job. If the stream itself drops instead, with frozen frames or a vanished device, stop: that is a link or firmware fault, and depth stream failures after a firmware update is the place to start. If the viewer opens the wrong device entirely, see viewer enumeration faults with consumer webcams.

The four causes, ranked by how often they bite

1. The generic Windows display driver is active. After a clean install or a failed driver update, Device Manager shows Microsoft Basic Display Adapter. The fallback stack has offered OpenGL 1.1-class support for years, and an OpenGL 3 renderer dies in it with exactly this error. This is the most common cause on freshly imaged bench and line PCs.
2. The viewer landed on the integrated GPU. On machines with both integrated and discrete graphics, Windows' per-application defaults can park the viewer on the integrated GPU, whose driver is often far behind the discrete one. The same executable renders on one GPU and crashes on the other.
3. The session is remote. Over remote desktop, Windows substitutes a software OpenGL stack of the same 1.1 vintage. The signature: the viewer renders at the bench console and dies the moment you take over the machine from a desk.
4. A stale shader cache or a driver regression. Viewers cache compiled shaders; after a driver or Windows update, cached programs can come back invalid. Less often, a specific driver release itself breaks a renderer that ran for months, and stepping back one version proves it.

Fix it in this order

Work down the list; each step either fixes the fault or eliminates a cause.

1. Identify the adapter. Open Device Manager and expand Display adapters. If the GPU's own name is missing and a generic Microsoft display adapter is listed instead, install the driver package for that exact GPU from the GPU or PC maker's support page, then reboot. This clears most fresh-install cases on its own.
2. Update, or clean-reinstall, the driver. An adapter carrying a driver several years old gets the current package. If a previous update was interrupted, uninstall the device with the delete-driver option, reboot, and install the fresh package. On a validated station, prefer the vendor's certified release over preview builds.
3. Force the discrete GPU. Windows keeps a per-application graphics preference — search Settings for graphics, add the viewer's executable, set it to the high-performance GPU, then close and relaunch the viewer. On boards with both chipsets, driving the monitor from the discrete GPU's own ports removes the choice altogether.
4. Leave remote desktop for 3D work. Render at the bench console. If the PC lives headless in a cabinet, a display emulator dongle gives it a real, accelerated head to drive. One safety note while you are at the bench: a laser profiler's projected line is not eye-safe at close range, so keep the guards closed and respect the camera's stated safety distance even for a two-minute render test.
5. Rebuild the viewer's shader cache. Run a viewer release from before the update once, close it, then run the current release again — the fresh first run recompiles the cache. Check the viewer's manual for a cache or configuration folder; clearing it does the same job.
6. Re-test the whole workflow, not just the opening screen: 3D preview, recording, export, overlay. If an export disagrees with the on-screen cloud afterwards, that is a separate investigation — see why exported point clouds differ from the viewer render.

Steps 1-3 fix the large majority of field cases; step 5 catches the after-update stragglers.

The arithmetic: it was never about memory

Before anyone orders new hardware, price the actual render. A typical mid-range depth frame carries 1,280 × 720 points, and viewers upload the cloud as three 32-bit floats per point.

For that frame: 1,280 × 720 = 921,600 points; × 12 bytes = 11,059,200 bytes, about 11 MB per frame; × 30 fps ≈ 332 MB/s of uploads. The 16-bit depth texture alongside it is 921,600 × 2 = 1,843,200 bytes ≈ 1.8 MB, and double-buffering the whole working set lands near 25 MB.

Entry-level discrete GPUs list 4 GB of memory, a margin of more than 150×; even a small integrated reservation of 512 MB leaves a factor of 20. Capacity is never the limiter here: a driver that cannot speak OpenGL 3 fails the shader and buffer calls before a single megabyte is at stake. That is the decision — a driver fault is cured by a driver, not by hardware. The same bandwidth arithmetic recurs on the network side: streaming depth data over a network works it for links, and updating overlay graphics every frame budgets the render path.

Which case are you in

Match the symptom to a row and act. None of the five cases is a camera fault, so none of them is fixed by reinstalling the SDK.

Every fix above lives on the PC side of the bench; the 3D topic page collects the camera-side equivalents, from deprojection maths to missing points in a 3D camera point cloud.

Keep the station from regressing

• Log the OpenGL version string. Viewers print it at start-up or list it in their about panel. A healthy station reads OpenGL 3.2 or newer; a station on the generic stack reads 1.1, and no 3D output from it should be trusted until the adapter is fixed.
• Freeze driver versions on validated stations. Test driver updates on the bench PC first, and record the driver version next to the GL string in the station file.
• Add a five-second render check to acceptance. If the cloud draws at the console during commissioning, the context is alive; re-check it after any Windows update.
• Borrow the fix across software. Engineering packages hit the same integrated-graphics OpenGL wall, and the same driver discipline clears it — this OpenGL driver error walkthrough for engineering software is the worked case. When a GPU fault escalates beyond a dead render to a full reboot with a DPC_WATCHDOG_VIOLATION stop code, the same clean-reinstall method applies, as in this GPU driver stop-code walkthrough. And when the viewing PC itself is next specified, pick hardware that ships with a current, vendor-supplied driver — for example among these industrial mini PCs.
• Keep the neighbouring faults straight. Washed-out colours in the render are the viewer's texture path, not the driver version — fix muted point-cloud colours. A cloud that vanishes inside Docker is GPU passthrough — point cloud black in Docker. A compute context lost after camera close is cleanup order — CUDA context invalid after camera close.