gemini-cli - 💡(How to fix) Fix gemini gemma forces CPU lockup in WSL2 due to hardcoded GPU model selection and missing Vulkan fullDrawIndexUint32 in Mesa Dozen

What happened?

When running gemini gemma setup or gemini gemma start inside an Ubuntu environment under Windows Subsystem for Linux (WSL2) on an NVIDIA-equipped machine, the CLI fails to initialize a functioning local model router.

The CLI forces the download of the gemma3-1b-gpu-custom model payload regardless of local configuration overrides. At runtime, the underlying Google Dawn/LiteRT engine attempts to initialize a Vulkan adapter. Under WSL2, the Mesa Vulkan translation driver (Dozen / dzn) does not support the desktop graphics feature fullDrawIndexUint32 required by Dawn. This causes the engine to report Found 0 adapters, triggering a fatal engine failure or an unoptimized CPU-melting fallback (llvmpipe) instead of an optimized CPU execution path.

Additionally, there is currently no command-line flag (such as --cpu-only) to bypass the hardware sniffer, and gemini gemma setup ignores "backend": "cpu" configurations in ~/.gemini/settings.json.

Environment:

• Host OS: Windows 11 (WSL2 Kernel)
• Guest OS: Ubuntu 26.04 LTS (x86_64)
• GPU: NVIDIA GeForce RTX 2050 (Discrete) + Intel Integrated Graphics
• Vulkan Instance Version: 1.4.341
• Mesa Driver Stack: Upstream ppa:kisak/kisak-mesa repository utilized to ensure the latest available Dozen (dzn) runtime capabilities.
• Vulkan Driver ID serving WSL2: DRIVER_ID_MESA_DOZEN (Mesa 26.1.0 - kisak-mesa PPA)
• CLI Version Context: Gemini CLI utilizing LiteRT-LM runtime (lit.linux_x86_64)

Steps to Reproduce:

1. Install Gemini CLI on an Ubuntu WSL2 instance hosted on an NVIDIA GPU laptop/desktop.

2. Ensure working CUDA and Mesa-Vulkan layers are present (vulkaninfo correctly enumerates the GPU via Microsoft Direct3D12 mapping).

3. Attempt to configure the local router: gemini gemma setup --force (Note: The prompt hardcodes the target to gemma3-1b-gpu-custom and ignores environment masks like CUDA_VISIBLE_DEVICES=-1).

4. Confirm the download and attempt to run the server: gemini gemma start

5. Check initialization telemetry via gemini gemma logs.

Expected Behavior:

The CLI should detect that the virtualized Vulkan layer cannot support the required WebGPU/Dawn features and gracefully fall back to an optimized, native CPU architecture backend (like XNNPACK). Alternatively, developers should have access to an explicit --cpu-only flag during setup or have the setup binary honor "backend": "cpu" entries inside ~/.gemini/settings.json.

Actual Behavior & Error Logs:

The engine crashes with an internal INTERNAL: No adapters found error because Google Dawn fails to find its mandatory graphics indices features on the Mesa translation wrapper:

I0000 00:00:1779030474.875117    2955 gpu_model_info_generator.cc:55] No Winograd
WARNING: dzn is not a conformant Vulkan implementation, testing use only.
WARNING: dzn is not a conformant Vulkan implementation, testing use only.

Warning: Vulkan fullDrawIndexUint32 feature required.
 - While initializing adapter (backend=BackendType::Vulkan)
    at InitializeImpl (third_party/dawn/src/dawn/native/vulkan/PhysicalDeviceVk.cpp:253)

I0000 00:00:1779030477.027813    2955 environment.cc:519] Found 0 adapters
E0000 00:00:1779030477.036140    2955 engine.cc:414] Failed to create engine: INTERNAL: No adapters found
=== Source Location Trace: ===
third_party/ml_drift/webgpu/environment.cc:550
third_party/ml_drift/webgpu/environment.cc:361
third_party/odml/infra/genai/inference/ml_drift/llm/llm_webgpu_runner.cc:129
third_party/odml/infra/genai/inference/ml_drift/llm/llm_webgpu_runner.cc:395
third_party/odml/infra/genai/inference/executor/llm_gpu_artisan_executor.cc:276
third_party/odml/litert_lm/runtime/core/engine_legacy_impl.cc:107
third_party/odml/litert_lm/runtime/core/engine_legacy_impl.cc:300

Root Cause Analysis:

1. Hardcoded Model Targeting: The linux-x64 installation path dynamically pushes the -gpu-custom payload if any hardware hooks are found, completely blinding the client to user constraints in settings.json.

2. Graphics vs. Compute API Mismatch: The routing framework uses a WebGPU/Vulkan graphics translation runtime (Google Dawn) to process LLM tokens. While native Linux partitions handle this easily, WSL2 handles GPU acceleration smoothly only via pure compute layers (CUDA/libcuda.so).

3. Missing Feature Map in Upstream Drivers: When forced onto Vulkan inside WSL2, the command chain goes through Microsoft's D3D12 mapping layer (dzn_icd.json). Even when leveraging the latest bleeding-edge drivers via the Kisak Mesa PPA, Google Dawn enforces a desktop-level graphic drawing feature (fullDrawIndexUint32) which is entirely absent in virtualized environments, leading to zero recognized adapters and complete execution failure.

Suggested Remediations / Feature Requests:

• Expose a CPU Override Flag: Add an explicit option to the setup script (e.g., gemini gemma setup --cpu) to force the standard, non-GPU CPU execution stack regardless of what the hardware sniffer detects.

• Honor Local Configuration Files: Ensure the setup wizard parses the ~/.gemini/settings.json file prior to selecting the model payload URI string, respecting user-declared "backend": "cpu" variables.

• Refine Runtime Fallbacks: If Google Dawn yields an INTERNAL: No adapters found return state, code an automatic internal redirection to launch an optimized CPU execution runtime instead of dropping or hard-locking the daemon process.

What did you expect to happen?

.

Client information

/about

╭───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮ │ │ │ About Gemini CLI │ │ │ │ CLI Version 0.42.0 │ │ Git Commit 68e2196d5 │ │ Model Auto (Gemini 3) │ │ Sandbox no sandbox │ │ OS linux │ │ Auth Method Signed in with Google (cole@<REMOVED>) │ │ Tier Gemini Code Assist │ │ GCP Project <REMOVED>

Login information

OAUTH w/ GCP Project Set.

Anything else we need to know?

No response