Comfy-Org / Comfy-Org/ComfyUI

GLSLShader fails on macOS because GLFW is hard-disabled while EGL/OSMesa fallback is unavailable

Open
#14,091 1 comment 2 reactions 0 assignees View on GitHub
Dominant language
Python
Stars
133k
Forks
15.7k
Avg merge
1d 7h
Merged PRs (30d)
158

Description

## Summary

`GLSLShader` fails on macOS because `comfy_extras/nodes_glsl.py` hard-disables GLFW on Darwin, then falls back to EGL/OSMesa paths that do not work on a current Apple Silicon/Homebrew setup.

On my machine, the GLSL workflow runs successfully after a small local patch that:

1. allows GLFW on macOS **only on the main thread**, and
2. prewarms the shared `GLContext` during startup so later worker-thread usage can reuse that context.

## Environment

- ComfyUI: `v0.22.0-29-gd80fcafe` (reported by startup log)
- Frontend: `1.43.18`
- Python: `3.11.15`
- PyTorch: `2.12.0`
- Device: Apple Silicon / `mps`
- Hardware: Apple M4 Max
- Launch args: `main.py --force-fp16 --highvram --use-split-cross-attention`
- Homebrew `mesa`: `26.0.6`
- `PyOpenGL`: installed
- `PyOpenGL-accelerate`: installed

## Current failure

Running a workflow with a `GLSLShader` node fails with:

```text
RuntimeError: Failed to create OpenGL context.

Backend errors:
GLFW: GLFW backend not supported on macOS
EGL: 'DarwinPlatform' object has no attribute 'EGL'
OSMesa: 'DarwinPlatform' object has no attribute 'OSMesa'
```

After installing `mesa` and `PyOpenGL-accelerate`, the failure changes but still does not work via fallback paths:

- `OSMesa` is still unavailable because current Homebrew `mesa` on macOS does not appear to ship `libOSMesa`
- `EGL` reaches `eglInitialize()` but returns `EGL_NOT_INITIALIZED`

So the current macOS help text in `nodes_glsl.py` is misleading/incomplete for current Homebrew Mesa.

## Why this looks fixable in ComfyUI

A direct GLFW test on the same machine works fine on macOS when done on the main thread:

- `glfw.init()` succeeds
- hidden `64x64` window creation succeeds
- `glfw.make_context_current()` succeeds
- renderer reports Apple/Metal OpenGL compatibility

The only thing that is *not* safe is trying to initialize GLFW from a worker thread.

## Minimal local fix that works here

In `comfy_extras/nodes_glsl.py`:

- change `_init_glfw()` from "always disable on macOS" to "allow on macOS only from the main thread"
- prewarm `GLContext()` once during module import / startup while still on the main thread

After doing that locally and restarting ComfyUI, the log shows:

```text
GLSL context initialized in 347.4ms (glfw) - Apple M4 Max (Apple), GL 4.1 Metal - 90.5
GLSL macOS GLFW context prewarmed on main thread
```

and the previously failing GLSL workflow runs successfully.

## Repro steps

1. On Apple Silicon macOS, start ComfyUI normally.
2. Use a workflow containing a `GLSLShader` node.
3. Queue the workflow.
4. Observe OpenGL context creation failure from `comfy_extras/nodes_glsl.py`.

## Suggested direction

Instead of hard-disabling GLFW on Darwin, consider:

- permitting GLFW on macOS when initialization happens on the main thread
- prewarming / caching the shared `GLContext` during startup on macOS
- keeping EGL/OSMesa as non-mac fallback paths
- updating the macOS error/help text, since `brew install mesa` alone does not provide a usable OSMesa fallback on my setup

## Extra note

I searched existing issues but didn't find one describing this exact macOS `GLSLShader` / GLFW-main-thread / missing-OSMesa combination.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.