cv2.checkHardwareSupport

"Does this CPU support this instruction set?" - one integer in, one boolean out. OpenCV ships it as checkHardwareSupport, the pack surfaces it as a raw node, and the honest use case is diagnostics: figuring out why a CPU-bound cv2 operation is crawling on one machine and fine on another, or confirming that the SIMD dispatch OpenCV is supposed to be using is actually live.

It's a raw wrapper in comfyui_cv (~470 cv2.* nodes). There's no image involved, and it reports nothing about your GPU - this is strictly about the CPU features OpenCV's own dispatch checks.

What the number is

The feature input takes one of OpenCV's CpuFeatures constants - the same numbers cv::checkHardwareSupport accepts in C++. 0, which is what the widget defaults to, is not a feature; it's just where an unstubbed required integer lands. The pack turns known enum-like parameters into dropdowns where the type stubs list the values, and this one stayed a raw INT, so you get no menu to pick from.

You're after numbers like AVX2 or AVX-512F, and the numbering comes from OpenCV's header rather than from anything friendly. If you're here to find out what your machine has, don't guess numbers one at a time - the pack exposes two better alternatives:

• cv2.getCPUFeaturesLine, another raw wrapper in the same catalog, returns the whole enabled-feature list as a string. One call, no archaeology.
• CV Build Information, the pack's curated node, prints a path-redacted getBuildInformation banner: build flags, CPU dispatch targets, the works. That's the node to reach for when you're diagnosing an install rather than a specific instruction set.

This node is for the other question: "is this specific feature present, as a boolean I can branch on". Keep it as a check inside a graph that routes between a fast path and a slow one, and keep the string/report nodes for humans.

Why it can matter here

Most of this pack is CPU work - OpenCV's filters, trackers and calibration routines all run on the host, and plenty of them have SIMD-optimised paths that kick in only when the CPU supports the relevant instruction set. Machine-level differences in speed are often exactly this. If a cv2.blur or a stitching job is inexplicably an order of magnitude slower on one box, a missing AVX2 (or OpenCV having been built without the dispatch target) is a mundane explanation, and this node is how you rule it in or out.

The output is a bool, so it also works as a switch selector: the same reasoning as any boolean gate in ComfyUI's plumbing layer.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/bmad4ever/comfyui_cv

Restart, or ComfyUI Manager → search "comfyui_cv". Python ≥ 3.12, a recent ComfyUI on the V3 node API, and:

pip install "opencv-contrib-python-headless~=5.0.0.93"

The wheel matters here in a way it doesn't for a filter node: opencv-contrib-python-headless ships a build with a particular dispatch configuration, and OpenCV's SIMD capabilities are baked in at compile time, not chosen at runtime. No models.

Common issues

It returns false for something your CPU definitely has. Either you passed the wrong number (very likely - there's no dropdown to help), or OpenCV was compiled without that dispatch target. Check getCPUFeaturesLine or the build-info node before concluding anything about the machine.

The number you typed does nothing / errors. The values are positionally defined in OpenCV's header, and the pack doesn't validate them for you. This is one of those nodes where reading the OpenCV source is genuinely the answer.

A corollary worth internalising: hardware support being present does not mean the fast path is being used. OpenCV enables and disables dispatch per function, sometimes with environment variables, and a debug build or an unusual wheel can have features present and unused. The feature check is necessary, not sufficient.

You were hoping this would tell you about CUDA. It won't. checkHardwareSupport is about CPU instruction sets; your GPU isn't in scope, and neither is whether torch is using it.