Run a 3D camera SDK on an unsupported compute device

A 3D camera SDK that does its point-cloud math on a compute device will refuse to start, or refuse to capture, on a PC whose hardware it does not list — and the error says nothing about whether that hardware could actually do the work. This page is for the engineer who has to get a 3D sensor running on the machine already on the bench. You will write the vendor's opt-in file, place it correctly on Windows and Ubuntu, measure what CPU-only mode costs against your takt time, and decide with numbers whether the fallback ships or stays on the bench.

Why does a 3D camera SDK refuse your compute device?

The SDK refuses the device because its point-cloud pipeline runs on OpenCL and accepts only the GPUs on its supported-device list, so a PC with a different GPU family — or none — fails the check at start-up, before any capture.

The refusal happens at device selection, not at the camera: the sensor streams over its normal link, and it is the deprojection stage — the step that turns each depth frame into a point cloud, worked through in depth map to point cloud: the deprojection calculation explained — that needs the compute device. The SDK maker keeps the list because it has run its full test matrix on those GPU families and driver versions, and on nothing else. The opt-in exists because many unlisted devices run the math correctly; what you give up is that testing, so unexpected results and errors become yours to debug.

Support is also not only added over time — it gets removed. SDK releases have dropped entire GPU families after OpenCL driver-stability problems in the field, so a card that worked last year can be off the list this year, and the file in the next section does not bring a removed device path back.

How do you opt in through the Config.yml file?

You opt in by writing a small YAML file — a Configuration: block with a ComputeDevice: key set to AllowUnsupported: yes — and placing it where the SDK looks for Config.yml; the next start then accepts whatever OpenCL device the PC reports.

You need a text editor and an installed SDK; the file is short enough to write by hand from the listing below, which is the content the vendor's knowledge base distributes:

__version__:
    serializer: 1
    data: 19
Configuration:
    ComputeDevice:
        AllowUnsupported: yes

Copy the version header exactly as your SDK's own guide prints it — the numbers identify the file format, and they change between SDK generations. Keep the two-space indentation and the lowercase yes. That is the whole change: Configuration is the top-level section, ComputeDevice selects the device policy, and AllowUnsupported: yes widens acceptance from the tested list to any OpenCL device the driver reports.

Nothing here touches the camera: no firmware, no network settings, no calibration. Delete the file later and the SDK reverts to its normal device selection on the next start.

Where does Config.yml go on Windows and Ubuntu?

The file lives in the SDK's own configuration folder under your user account — beneath %LOCALAPPDATA% on Windows or ~/.config on Ubuntu — inside an API subfolder, under the exact name Config.yml.

Place it in five steps:

1. Close every application that uses the SDK.
2. Create the configuration folder if it does not exist: under %LOCALAPPDATA% on Windows, or ~/.config on Ubuntu (or the folder $XDG_CONFIG_HOME points to), create the folder named for the SDK, with an API subfolder inside it. The SDK's installation guide prints the full path.
3. Save the listing from the previous section into that API folder as Config.yml.
4. If a Config.yml is already there, copy any settings you need out of it first — the new file replaces it.
5. Start the application and capture one frame. If the SDK still reports the device as unsupported, the file is in the wrong user's folder or has the wrong extension — see the warning below.

Can a 3D camera SDK run on the CPU alone?

Yes — with Intel's CPU Runtime for OpenCL installed and Type: CPU plus Vendor: Intel added alongside the opt-in, the SDK will run its pipeline on an Intel processor, at a capture-time cost the SDK's own notes call greatly increased.

Two things have to be in place. First, Intel's CPU Runtime for OpenCL, installed from Intel's own download area for your processor generation — the SDK enumerates OpenCL devices, and without that runtime a processor never appears as one. Second, a config file with the two extra keys:

__version__:
    serializer: 1
    data: 19
Configuration:
    ComputeDevice:
        Type: CPU
        Vendor: Intel
        AllowUnsupported: yes

Type: CPU and Vendor: Intel tell the SDK what the unlisted device is; AllowUnsupported: yes still does the admitting.

Why so slow? The deprojection, filtering and coordinate transforms are written for thousands of GPU threads working at once, while an OpenCL CPU runtime maps the same work onto a handful of processor cores that share memory bandwidth with everything else on the box. The same compute-budget logic decides small embedded designs — see when a microcontroller can and cannot carry vision compute — and it ends the same way: the processor finishes the job, just not at line rate.

How much capture time does CPU-only mode cost?

Expect several times slower: the SDK's own caution says capture time is greatly increased on CPU, so measure the factor on your machine — CPU capture time divided by GPU capture time — and compare it against the seconds per part your line allows.

Measure on the machine you will ship, because the factor moves with processor generation, memory speed and point-cloud size. Capture the same scene twenty times on the supported GPU and take the mean; repeat on the CPU; the ratio is your factor. Time it in your own code, not in the viewer — the two numbers differ, as 3D camera capture time slower in the API than in the viewer shows.

Worked example, with example times you replace with your own measurements: a cell feeds 15 parts per minute, so takt = 60 / 15 = 4.0 s per part. On the supported GPU the SDK returns a point cloud in 1.0 s. On the CPU the same capture runs at a 4.0× factor: 1.0 s × 4.0 = 4.0 s. That equals the whole takt with nothing left for part handling, so CPU-only mode fails this line. The same 4.0× factor on a cell running 8 parts per minute gives takt = 60 / 8 = 7.5 s and leaves 7.5 − 4.0 = 3.5 s of margin, so the fallback carries that slower cell.

If even the supported GPU feels slow, the bottleneck may be your own processing rather than the device — slow GPU image processing: diagnose low frame rates walks that diagnosis. With more than one camera per cycle the capture times stack, which multi-camera 3D processing performance: plan throughput helps you budget. More point-cloud and capture-time fixes sit on the 3D vision topic page.

When is an unsupported compute device good enough?

The unsupported device is the right choice on the bench and for offline analysis, where a slow capture costs nothing, and the wrong choice on a production line unless your measured CPU capture time fits the cycle budget with margin to spare.

Use it deliberately, in three places:

• Bench feasibility. Testing whether a 3D sensor solves the task before you buy compute for it costs nothing but patience — a 4 s capture still answers the geometry question.
• Offline analysis. Rework analysis, first-article checks and archived-capture reprocessing run in minutes, not milliseconds, so the factor is irrelevant.
• Driver debugging. If a suspect GPU driver is the question, a CPU capture gives you a clean reference to compare against.

Production is different in kind, not just degree. The combination of your processor, the OpenCL runtime and the SDK has no vendor testing behind it, so a corrupted cloud, a crash under memory pressure or a result that drifts with load lands on your validation. If you do ship it, write the config file into your deployment so every station runs the same policy, and keep one GPU capture as the baseline.

What should a production 3D camera station run on?

Production belongs on a GPU from the SDK's supported list, hosted with the camera, its lights and the trigger wiring in one box, because the supported-list check — not a config file — is what keeps ten stations behaving identically.

The controller decision is separate from the GPU decision and easier: match the network the camera asks for — LAN ports, PoE if the sensor takes power over the link — the light channels for the illumination side, and memory for the point clouds you keep. Three matches settle any order: the SDK's supported-device list against the machine's GPU and driver version; the camera's connection needs against the LAN ports; and your point-cloud memory footprint against RAM.

An entry box for a single-camera bench cell, vision software licence included:

A full station host with PoE camera ports for the 3D sensor and 8 built-in light channels, so the illumination wiring never leaves the controller:

When the SDK shares the controller with your own inference or a second sensor, the Intel Core Ultra 7 255H class with 16 GB × 2 memory and PCIe expansion gives the box somewhere to grow:

The vision controllers range runs from compact fanless boxes to PCIe-expansion units, and the camera finder filters 3D sensors by profiler, structured-light and logistics types. Send the SDK's supported list and the camera model through the contact page and we will match the controller to both.