gpu passtrough moved to separate file

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

@@ -0,0 +1,185 @@
+# 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.
+