scripts/portainer-compose-stacks/windows/GPU-SHARING-EXPLAINED.md

GPU Sharing: Windows vs Linux Explained

Can You Share GPU Between Host and Container?

Short Answer: No, not with VFIO PCI passthrough on Linux.

Why Windows Can Do It (Hyper-V GPU-PV)

Windows Hyper-V GPU Paravirtualization

• Technology: Microsoft's proprietary GPU virtualization
• How it works: GPU stays with Windows host, VMs get "virtual GPU slices"
• Requirements:
  • Windows host (Server or Pro with Hyper-V)
  • Windows guests
  • Specific GPU support (mostly newer Intel/AMD/NVIDIA)
• Benefits:
  • ✓ Multiple VMs share one GPU
  • ✓ Host keeps display working
  • ✓ Decent performance for most workloads
• Limitations:
  • Windows only (host + guest)
  • Not full GPU performance
  • Limited GPU features

Why Linux QEMU/VFIO Can't Share

VFIO PCI Passthrough

• Technology: Hardware-level device passthrough (Linux kernel feature)
• How it works: Entire GPU is "unplugged" from host and given to guest
• Benefits:
  • ✓ Near-native performance
  • ✓ Full GPU features
  • ✓ Works cross-platform (any guest OS)
• Limitations:
  • ✗ Exclusive access only (either host OR guest)
  • ✗ Host loses display when GPU passed through
  • ✗ Cannot share between multiple VMs

Your Options for AMD Strix Halo iGPU

Option 1: Shared Software Rendering (Recommended)

Configuration: No GPU passthrough

How it works:

• Host uses GPU normally (amdgpu driver)
• Windows container gets VirtIO virtual GPU
• Both host and container work simultaneously
• Software rendering in container (accelerated by host GPU)

Pros:

• ✓ Host display works
• ✓ Container auto-starts
• ✓ Both usable at same time
• ✓ Simple, no binding scripts

Cons:

• ✗ No native GPU in Windows
• ✗ Limited GPU performance in Windows
• ✗ No GPU-Z, no AMD drivers in Windows

Best for:

• General Windows usage
• When you need host display
• Development/testing
• Light workloads in Windows

Current docker-compose setup: This is now configured (I just updated it)

---

Option 2: Exclusive GPU Passthrough

Configuration: VFIO PCI passthrough (manual binding)

How it works:

1. Bind GPU to VFIO (host display freezes)
2. Start Windows container
3. Windows gets real AMD GPU
4. Stop container and unbind to restore host

Pros:

• ✓ Full AMD GPU in Windows
• ✓ Native performance
• ✓ GPU-accelerated apps work
• ✓ AMD drivers install

Cons:

• ✗ Host display frozen (no GUI)
• ✗ Exclusive - can't use both
• ✗ Manual binding required
• ✗ Access host via SSH only

Best for:

• GPU-intensive Windows apps
• Machine learning in Windows
• Gaming (if that's possible)
• When maximum GPU performance needed

Workflow:

# Start Windows with GPU
sudo ./bind-gpu-to-vfio.sh    # Host display goes black!
docker compose -f docker-compose.gpu-passthrough.yml up -d

# Stop and restore
docker compose -f docker-compose.gpu-passthrough.yml down
sudo ./unbind-gpu-from-vfio.sh

---

Technologies That DON'T Work Here

SR-IOV (Single Root I/O Virtualization)

• Requires GPU hardware support
• Consumer GPUs (like Strix Halo) don't have it
• Mostly enterprise data center GPUs

AMD MxGPU / NVIDIA vGPU

• Enterprise GPU virtualization
• Requires special drivers + licensed enterprise GPUs
• Not available for consumer iGPUs

GVT-g (Intel GPU Virtualization)

• Intel only
• Not available for AMD GPUs

Looking Glass

• Allows viewing GPU output from guest
• Still exclusive passthrough (guest owns GPU)
• Just a viewer, not sharing

What About DRI/DRM Passthrough?

You might think: "Can we pass /dev/dri to share?"

Tried this already - it doesn't work for Windows because:

• Windows needs PCI-level GPU access
• /dev/dri is Linux-specific (won't work in Windows)
• Windows drivers expect real PCI GPU device

Comparison Table

Feature	Shared (VirtIO)	Exclusive (VFIO)	Windows Hyper-V GPU-PV
Host display works	✓	✗	✓
Container auto-start	✓	✗	✓
Both usable together	✓	✗	✓
Native GPU in Windows	✗	✓	~ (virtual)
GPU performance	Low	High	Medium
Setup complexity	Easy	Complex	Medium
Requires manual binding	✗	✓	✗

Recommendation

For your use case, I recommend:

Start with Option 1 (Shared - No Passthrough)

• Container works
• Host works
• Both at same time
• Simple setup

If Windows GPU performance is too slow, then consider:

• Adding a second GPU to host (dedicate one to passthrough)
• Running Windows on bare metal for GPU workloads
• Using cloud GPU instances for heavy GPU tasks

Current Configuration

I've just updated your docker-compose.yml to Option 1 (Shared):

• Removed GPU passthrough
• Removed VFIO devices
• Container can auto-start
• Host display continues working

Want to test it?

cd /mnt/shared/DEV/repos/d-popov.com/scripts/portainer-compose-stacks/windows
docker compose up -d

Windows will start with VirtIO display. Both host and container will work simultaneously.

Need GPU passthrough later? I can create a separate docker-compose file for that use case.