# MVGAL Feasibility and Gap Audit

Updated: 2026-05-30

This audit records what MVGAL can implement safely on stock Linux kernels and what remains blocked by vendor-private command submission, memory-management, and compiler interfaces.

## Executive Conclusion

MVGAL can be a practical above-driver coordination layer. It can enumerate GPUs, expose `/dev/mvgal0`, provide a user-space API, run explicit multi-device compute demos, choose Vulkan/OpenCL/CUDA/SYCL devices, coordinate DMA-BUF or host-staging transfers, and manage power policy through standard Linux interfaces.

MVGAL cannot honestly make arbitrary unmodified applications see every heterogeneous GPU as one native GPU with perfect transparent scaling. Modern graphics APIs compile pipelines, allocate memory, submit command buffers, and synchronize through vendor-specific driver stacks. A cross-vendor "one GPU" abstraction must therefore be implemented per API and per workload class, with clear capability reporting and fallback paths.

## Upstream Repositories Checked

Local shallow clones were created in `/tmp/mvgal-vendor-research`:

| Vendor | Repository | Result |
|--------|------------|--------|
| NVIDIA | `https://github.com/NVIDIA/open-gpu-kernel-modules` | Cloned and inspected |
| AMD | `https://github.com/GPUOpen-Drivers/AMDVLK` | Cloned and inspected; upstream README marks project discontinued |
| Intel | `https://github.com/intel/media-driver` | Cloned and inspected |
| Moore Threads | `https://github.com/dixyes/mtgpu-drv` plus official Moore Threads driver/SDK docs | Community source provenance still pending; official docs show `mtgpu.ko`, MUSA, and MTML surfaces |

The task text names MTT as `dixyes/mtgpu-drv`. Public Moore Threads docs show a Linux `mtgpu.ko` DRM driver with Dual MIT/GPL metadata and MUSA/MTML user-space tooling. MVGAL should still treat MTT support as optional until source provenance, license, and version mapping are confirmed in a reproducible audit.

## Driver Initialization Boundaries

### NVIDIA

Observed in `open-gpu-kernel-modules`:

- `kernel-open/nvidia/nv.c` registers character devices for `nvidia` and `nvidiactl` and calls `nv_pci_register_driver()`.
- `kernel-open/nvidia/nv-pci.c` registers `nv_pci_driver` with the Linux PCI core.
- `kernel-open/nvidia-drm/nvidia-drm-drv.c` allocates and registers DRM devices with `drm_dev_alloc()` and `drm_dev_register()`.
- `kernel-open/common/inc/nv-ioctl.h` and `kernel-open/common/inc/nv-dmabuf.h` expose ioctl and DMA-BUF related structures used by NVIDIA's driver stack.

MVGAL extension point: enumerate and coordinate NVIDIA through PCI, DRM render nodes, Vulkan/CUDA/OpenCL APIs, DMA-BUF where supported, and NVIDIA peer-memory features only behind capability probes. MVGAL should not attempt to submit native NVIDIA command buffers from its kernel module.

### AMD

Observed in `AMDVLK`:

- The top-level README states AMDVLK is built from LLVM, XGL, LLPC, GPURT, and PAL.
- The README states the project is discontinued.
- The repository is a source manifest/top-level build entry, not the kernel `amdgpu` driver.

MVGAL extension point: use AMD through standard Linux `amdgpu`/DRM, Mesa/RADV or AMDVLK ICD discovery, OpenCL/ROCm where present, and DMA-BUF/PRIME. PAL and LLPC internals are useful references but not stable MVGAL integration ABIs.

### Intel

Observed in `media-driver`:

- The project is a VA-API user-mode media driver for decode, encode, and video processing.
- README build output installs `iHD_drv_video.so` and `igfxcmrt64.so`.
- `cmrtlib` is a runtime for C for Metal kernels that calls the iHD media driver.
- Source references show `vaInitialize()`, DRM/i915 interaction, GPU contexts, and command buffers, but this repository is not a general Vulkan/OpenGL driver.

MVGAL extension point: model Intel media-driver as encode/decode/video-processing capability. General Intel graphics or compute aggregation should go through DRM render nodes, Mesa/ANV, Level Zero, OpenCL, or SYCL rather than the media-driver alone.

### Moore Threads

The repository URL supplied in the task failed to clone on 2026-05-30. Existing MVGAL docs mention `dixyes/mtgpu-drv`; that source should be audited separately before claiming MTT production support.

MVGAL extension point: capability-probed optional backend only. Required runtime behavior is graceful degradation when MTT driver nodes, PRIME/DMA-BUF support, telemetry, or compiler tools are absent.

## Workload Flow Design

MVGAL should use three workload classes:

1. Explicit multi-device compute: split kernels or data chunks across devices that expose a compatible API. This is feasible for OpenCL/SYCL/MPI-style workloads and benchmark demos.
2. API-mediated graphics: intercept Vulkan/OpenGL swap/submit paths and apply AFR/SFR only when resources, synchronization, and presentation semantics are compatible. Default to single-GPU pass-through when unsafe.
3. Specialized offload: route video encode/decode, ray tracing, AI inference, or copy work to devices that advertise the required capability.

The scheduler should score devices by required API support, queue/engine support, VRAM pressure, PCIe topology, measured transfer bandwidth, thermal/power headroom, historical latency, and user policy.

## Memory and Data Flow Design

MVGAL should expose a logical allocation API, but internally every allocation needs an explicit residency model:

- Preferred path: DMA-BUF/PRIME export-import when both endpoints support it and the buffer type is shareable.
- Fast path: vendor-specific peer memory only when both driver and topology capability probes succeed.
- Portable path: pinned host staging with explicit copies and fences.
- Fallback path: single-GPU ownership with migration only at API-safe synchronization points.

The unified heap must report non-coherent behavior honestly. Cross-vendor coherent VRAM is not a stock Linux feature; MVGAL can provide managed migration, not magic shared VRAM.

## Required Missing Functionality

| Area | Required gate |
|------|---------------|
| Vendor provenance | Cloneable, licensed, documented MTT source selected and audited |
| Kernel UAPI | `/dev/mvgal0` must expose stable caps, topology, stats, enable/disable, and unsupported-operation counters |
| DMA-BUF | Hardware validation matrix for AMD/NVIDIA/Intel/MTT import/export combinations |
| Vulkan | Conformance-style tests proving layer/ICD fallback does not break normal single-GPU apps |
| Compute PoC | Real OpenCL/SYCL benchmark that verifies work ran on at least two physical GPUs |
| Power | Per-vendor power-limit writes restricted to Polkit/pkexec path with dry-run support |
| Claims | README/status must label synthetic tests, hardware tests, and unsupported transparent scaling separately |

## References

- NVIDIA open-gpu-kernel-modules: https://github.com/NVIDIA/open-gpu-kernel-modules
- AMDVLK: https://github.com/GPUOpen-Drivers/AMDVLK
- Intel media-driver: https://github.com/intel/media-driver
- Moore Threads developer docs: https://developer.mthreads.com/
- Linux DRM GPU driver UAPI: https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html
- Vulkan device groups: https://registry.khronos.org/vulkan/specs/latest/html/chap12.html
- DMA-BUF: https://www.kernel.org/doc/html/latest/driver-api/dma-buf.html
