windows: fix VK_ERROR_DEVICE_LOST - give the D3D-interop blit its own VkQueue

[nobandegani]

Problem

On Windows with newer NVIDIA hardware/drivers, any Thermion app dies as soon as rendering starts:

Initializing WindowsVulkanContext
vkQueueSubmit failed: -4          <- VK_ERROR_DEVICE_LOST
vkWaitForFences failed: -4        <- repeats every frame afterwards

sometimes followed by a native abort through Filament's timer-query postcondition (vkGetQueryPoolResults error=-4). Reproduced with the unmodified examples/flutter/quickstart at 89c135b on:

• GPU: NVIDIA GeForce RTX 5090 (Blackwell)
• Driver: 610.62 (32.0.16.1062, 2026-06), Vulkan API 1.4.341
• OS: Windows 11 Pro 26200

The device is lost on the first frame; the viewport stays blank (or shows the app's clear color) and the app eventually aborts.

Root cause

createLogicalDevice requests a single queue (queueCount = 1) in the graphics family. Two independent code paths then fetch the same VkQueue:

1. Filament, via VulkanSharedContext (graphicsQueueFamilyIndex, graphicsQueueIndex = 0), submitting from its render thread;
2. createCommandResources (vkGetDeviceQueue(device, family, 0)), used by the D3D-interop Blit() submitting from the Flutter platform thread.

Per the Vulkan spec, queue access is externally synchronized — vkQueueSubmit on the same queue from two threads without host synchronization is invalid. Many driver generations happen to tolerate it, which is why this hasn't bitten on existing hardware; the current NVIDIA driver for Blackwell rejects the first concurrent submission with VK_ERROR_DEVICE_LOST.

Fix

Request two queues from the graphics family when the hardware exposes more than one (NVIDIA exposes 16; the request is clamped to the family's queueCount):

• queue 0 remains exclusively Filament's, exactly as before;
• queue 1 is used by createCommandResources for the blit/command path.

Both queues are in the same family, so no queue-family ownership transfers are needed and the existing barriers/fences are unchanged. On hardware exposing a single graphics queue (queueCount == 1) the behavior is byte-for-byte the old one, so nothing regresses on platforms where the shared queue happened to work.

Validation

• Before: examples/flutter/quickstart reproduces the device loss on the first frame (hardware above).
• After: quickstart and a full app (113 MB character glTF with skin + morph targets) render correctly; no Vulkan errors across repeated runs, window resizes, and viewer re-creation.
• A diagnostic line logs the chosen queue at startup: [INFO] Blit/command queue: family 0, queue index 1.

Happy to adjust if you'd prefer a different split (e.g. a dedicated transfer-family queue) — this is the minimal change that makes the existing design valid.

🤖 Generated with Claude Code