186 lines
5.1 KiB
Markdown
186 lines
5.1 KiB
Markdown
# 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**:
|
|
```bash
|
|
# 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?**
|
|
```bash
|
|
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.
|
|
|