lanedfritz/fooocus-intel-arc-xpu-b70 repository overview

⁠Fooocus on Intel Arc (XPU)

A working Fooocus⁠ image generation stack running natively on Intel Arc GPUs (tested on Arc Pro B70 / Battlemage) via PyTorch XPU. No NVIDIA hardware required.

Docker image: lanedfritz/fooocus-intel-arc-xpu-b70⁠

⁠Requirements

• Linux host with an Intel Arc GPU (Alchemist, Battlemage, or newer)

• Docker and Docker Compose installed

• Intel xe kernel driver loaded (lsmod | grep xe should show output)

• Intel compute runtime installed on the host (level-zero + OpenCL), matching versions:

  • intel-opencl-icd
  • libze-intel-gpu1
  • libze1
  • libigc2, libigdfcl2, libigdgmm12 (Intel Graphics Compiler libs)

  Install via Intel's GPU repository:

  wget -qO- https://repositories.intel.com/gpu/intel-graphics.key | sudo gpg --dearmor -o /usr/share/keyrings/intel-graphics.gpg
  echo "deb [arch=amd64 signed-by=/usr/share/keyrings/intel-graphics.gpg] https://repositories.intel.com/gpu/ubuntu noble unified" | sudo tee /etc/apt/sources.list.d/intel-graphics.list
  sudo apt update
  sudo apt install -y intel-opencl-icd libze-intel-gpu1 libze1 libigc2 libigdfcl2 libigdgmm12
  

  Copy

• Your user must be in the render group, and you need to know its GID:

  stat -c '%g' /dev/dri/renderD128
  

  Copy

  This stack assumes GID 991. If yours differs, update group_add in the compose file accordingly.

⁠Setup

⁠1. Create data directories

mkdir -p /your_path_for_models_and_output/fooocus/{checkpoints,loras,vae,embeddings,controlnet,upscale_models,inpaint,outputs}

(Adjust the base path to wherever you want persistent data stored.)

⁠2. Create the compose file

Save as docker-compose.yaml:

services:
  fooocus:
    image: lanedfritz/fooocus-intel-arc-xpu-b70:latest
    container_name: fooocus
    restart: unless-stopped
    ports:
      - "7865:7865"
    volumes:
      - /your_local_path/fooocus/checkpoints:/fooocus/models/checkpoints
      - /your_local_path/fooocus/loras:/fooocus/models/loras
      - /your_local_path/fooocus/vae:/fooocus/models/vae
      - /your_local_path/fooocus/embeddings:/fooocus/models/embeddings
      - /your_local_path/fooocus/controlnet:/fooocus/models/controlnet
      - /your_local_path/fooocus/upscale_models:/fooocus/models/upscale_models
      - /your_local_path/fooocus/inpaint:/fooocus/models/inpaint
      - /your_local_path/fooocus/outputs:/fooocus/outputs
    devices:
      - /dev/dri/renderD128:/dev/dri/renderD128
      - /dev/dri/card0:/dev/dri/card0
    group_add:
      - "991"
    environment:
      - ONEAPI_DEVICE_SELECTOR=level_zero:0

⁠3. Launch

docker compose up -d
docker logs fooocus -f

First launch will download the default SDXL checkpoint (Juggernaut XL, ~6.6GB) and a default LoRA (~47MB) into your mounted checkpoints/loras folders. This only happens once.

⁠4. Access

Open http://<host-ip>:7865 in a browser.

⁠Known limitations

• Fooocus's prompt-expansion engine runs on CPU, not XPU — this is expected and causes brief CPU spikes alongside GPU compute during generation.
• GPU monitoring tools like intel_gpu_top and xpu-smi do not yet support the xe driver / Battlemage and will show 0% or fail outright, even while the GPU is actively working. Use nvtop (recent versions) or check /sys/class/drm/card0/device/... directly for accurate Battlemage telemetry, or monitor power/clock/VRAM rather than the unsupported utilization metric.
• This stack uses Fooocus's bundled gradio 3.41.2 with several dependency pins (jinja2, starlette, fastapi, anyio, pydantic, huggingface-hub) held at specific versions for compatibility with the modern PyTorch XPU base image. Upgrading any of these independently may break the UI.

⁠Troubleshooting

XPU not detected / falls back to CPU: Confirm the host's level-zero stack is healthy:

python3 -c "import ctypes; ze = ctypes.CDLL('libze_loader.so.1'); print(ze.zeInit(0))"

Should print 0. If it errors, your host compute runtime isn't installed correctly.

Container can't access /dev/dri: Confirm device permissions and your render group GID match what's in the compose file:

ls -la /dev/dri/
stat -c '%g' /dev/dri/renderD128

UI loads but generation never completes / buttons don't revert: Check the container logs — if image files are still appearing in your outputs folder despite the UI looking stuck, the queue/UI sync intermittently lags under gradio 3.41.2's internal self-call mechanism. Refreshing the page after a moment will pick up completed results from the History tab even if the live gallery doesn't update.