# MVGAL Upstream Research and Reference Report 2026

This document fulfills the research phase requirements of the MVGAL project by providing an architectural analysis of upstream drivers, reference multi-GPU frameworks, and Windows compatibility layers.

## 1. Upstream Driver Source Analysis

### NVIDIA Open GPU Kernel Modules
**Source**: `nvidia/open-gpu-kernel-modules`
- **Architecture**: Split driver model. The kernel portion primarily handles interrupt routing, BAR mapping, and DMA-BUF export. The heavy lifting for command submission and hardware initialization is offloaded to the GSP (GPU System Processor) firmware.
- **Memory Model**: Unified Virtual Memory (UVM) enables page migration between system RAM and VRAM.
- **Command Submission**: RM (Resource Manager) manages the queues, but the exact command stream format is largely proprietary and constructed in userspace (NVK or NVIDIA's proprietary ICD).

### AMD Vulkan Driver (AMDVLK & RADV)
**Source**: `GPUOpen-Drivers/AMDVLK` and Mesa
- **Architecture**: Open source stack built on PAL (Platform Abstraction Library) for AMDVLK, or ACO/RADV in Mesa.
- **Memory Model**: Uses GEM (Graphics Execution Manager) handles exported via `amdgpu` kernel driver. It heavily utilizes DMA-BUF and implicit/explicit fences.
- **Command Submission**: Ring buffers are constructed in userspace and submitted via the `AMDGPU_CS` ioctl. It fully supports `VK_KHR_device_group` internally for same-vendor GPUs.

### Intel Media Driver / Xe Graphics
**Source**: `intel/media-driver` and `i915/xe` kernel drivers
- **Architecture**: The `xe` driver (Gen 12+) redesigns the execution model around GuC (Graphics microController).
- **Memory Model**: Relies heavily on host-visible mapped memory and explicit synchronization.
- **Command Submission**: Uses `execbuf3` (in the `xe` driver) for submitting batch buffers.

### Moore Threads (MTT)
**Source**: `dixyes/mtgpu-drv`
- **Architecture**: Exposes a standard DRM interface mimicking aspects of `amdgpu`.
- **Memory Model**: Supports standard GEM allocations and DMA-BUF export.
- **Command Submission**: Custom job submission ioctls with explicit fence objects.

## 2. Multi-GPU Reference Frameworks

### Hardware Interconnects
- **NVLink / Infinity Fabric**: High-bandwidth, low-latency inter-GPU connections. Allow peer-to-peer (P2P) memory access bypasses the CPU root complex.
- **PCIe P2P**: Uses Resizable BAR to map the memory of one GPU into the MMIO space of another, allowing direct DMA transfers.

### Distributed Compute Frameworks
- **CUDA Multi-GPU**: Explicit API calls (`cudaDeviceEnablePeerAccess`) to map peer memory. Data is explicitly transferred or implicitly fetched on page fault.
- **NCCL / MPI**: Utilizes all-reduce, scatter-gather, and broadcast operations. Highly optimized for topologies (ring, tree) to minimize latency.
- **PyTorch/TensorFlow Distributed**: Shards tensors across GPUs. The synchronization is implicit in the backward pass of neural network training.
- **FluidX3D**: A monolithic OpenCL simulation that divides the 3D fluid grid into slices, one per GPU, with halo exchange across boundaries.

## 3. Windows Compatibility Layers

### Wine and Proton
- **Architecture**: Wine translates Windows API calls to POSIX/Linux equivalents. Proton adds optimizations like DXVK (D3D9-11 to Vulkan) and VKD3D-Proton (D3D12 to Vulkan).
- **GPU Interaction**: They translate DirectX directly to Vulkan. To support multi-GPU under Proton, MVGAL must intercept the Vulkan calls made by DXVK/VKD3D.

### Synchronization (Esync, Fsync, NTSYNC)
- **Problem**: Wineserver synchronization is slow due to context switching.
- **Esync**: Uses Linux `eventfd` to back Windows events.
- **Fsync**: Uses Linux `futex` to back Windows mutexes and semaphores.
- **NTSYNC**: A proposed kernel module that natively implements Windows NT synchronization primitives in the Linux kernel. MVGAL requires its own implementation of these primitives for tight, low-latency GPU-CPU syncing in Windows titles.

### WoW64 (Windows 32-bit on Windows 64-bit)
- **Purpose**: Allows 32-bit Windows games to run on a 64-bit Wine host without needing a 32-bit Linux graphics stack.
- **Mechanism**: A thunking layer translates 32-bit pointers and calling conventions (e.g., `stdcall`) to 64-bit System V ABI before invoking the 64-bit OpenGL/Vulkan/MVGAL driver.
