Populate 'type' options by sourcing from core nodes to avoid drift:\n- CLIPLoaderGGUF now derives 'type' from nodes.CLIPLoader.INPUT_TYPES()\n- DualCLIPLoaderGGUF now derives 'type' from nodes.DualCLIPLoader.INPUT_TYPES()\nThis fixes missing or outdated 'type' options in GGUF Single and Dual CLIP loaders.\n\nchore: bump version to 1.8.2
Add guarded Intel XPU support alongside CUDA:
- get_device_list now includes xpu:N when available
- device selection (model/text encoder) considers CUDA or XPU and validates devices
- DisTorch donor/offload selection includes xpu devices
Also: remove unused MergeFluxLoRAs node and mapping; delete tools/ and precompiled_binaries/; bump project version to 1.8.1.
Problem: WanVideoWrapper caches device at module load time, causing timesteps
and tensors to be created on wrong device when looping between models on
different GPUs.
Solution: WanVideoSamplerMultiGPU wrapper updates module-level device variable
to match current model's device before sampling.
Changes:
- Added comprehensive logging to trace device allocation through pipeline
- Identified module-level device caching as root cause
- Simplified WanVideoSamplerMultiGPU to only update device variable
- Verified fix works for multi-model workflows with looping
- Created custom implementations for all WanVideo nodes with explicit device selection
- Added WanVideoBlockSwap with dual device control (swap_device and model_offload_device)
- Created WanVideoModelLoader_TWO for multi-model workflows to avoid race conditions
- Discovered core ComfyUI bug: safetensors loader ignores device index (uses device.type instead of str(device))
- All wrapper nodes use runtime module patching to override WanVideoWrapper's cached device variables
- Extensive logging added for debugging device assignments
In Windows, module detection was failing because the method couldn't find the hard-coded custom_nodes/ folder in os.join.path.
We switch to using folder_paths which will return a correct path regardless of the platform.
Actual nodes pick up the underlying structure at runtime now that the global NODE_CLASS_MAPPINGS has been updated with their information, I pull it directly from there.
A work-around for the loading sequencing problems, but hopefully one that requrires little upkeep as any changes to the underlying structure is picked-up at runtime.
- Added a local_map_name ("NODE_CLASS_MAPPINGS") and retrieve it from the module
immediately after loading.
- If the local dictionary exists, wrap the target nodes from there, rather than
relying on the global dictionary.
- Removed references to GLOBAL_NODE_CLASS_MAPPINGS for custom nodes and replaced
them with the local module mapping lookup.
John Pollock