# 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.