# Upstream Driver Research Snapshot

Updated: 2026-05-30

This document captures the current research boundary for MVGAL. It is not a promise that MVGAL can transparently merge arbitrary vendor command streams; it defines the safe integration points for an above-driver aggregation layer.

## Executive Boundary

MVGAL should coordinate existing vendor drivers rather than replacing them. Kernel code may expose topology, capability, DMA-BUF/fence plumbing, and policy controls. API-specific user-space layers decide when work can be split, migrated, or offloaded. Unsupported paths must remain pass-through.

## NVIDIA open-gpu-kernel-modules

Source: <https://github.com/NVIDIA/open-gpu-kernel-modules>

Observed upstream characteristics:

- The tree is a source release for NVIDIA Linux open GPU kernel modules.
- NVIDIA documents a split between Linux kernel-interface code and OS-agnostic components.
- `kernel-open/` contains Linux-facing modules such as `nvidia`, `nvidia-drm`, `nvidia-modeset`, and `nvidia-uvm`; `src/` contains OS-agnostic code.
- The open kernel modules require matching GSP firmware and matching NVIDIA user-space driver components.
- Supported open-module hardware begins at Turing or later, per upstream README.

MVGAL implications:

- Do not attempt cross-vendor resubmission of native NVIDIA command buffers from MVGAL kernel code.
- Use PCI/DRM enumeration, Vulkan/CUDA/OpenCL user-space APIs, DMA-BUF where available, and peer-memory capabilities only behind probes.
- Treat UVM as a design reference for residency and migration semantics, not as a stable cross-vendor UVM ABI.

## AMDVLK / PAL

Source: <https://github.com/GPUOpen-Drivers/AMDVLK>

Observed upstream characteristics:

- AMDVLK is a user-space Vulkan driver for Radeon GPUs on Linux.
- Upstream describes AMDVLK as built on PAL, with LLPC compiling Vulkan pipeline shaders to PAL-compatible code objects.
- The upstream README currently marks the AMDVLK open-source project as discontinued.
- Kernel services are provided by the normal AMDGPU/DRM stack rather than by AMDVLK.

MVGAL implications:

- Use AMD through standard DRM render nodes, Mesa/RADV or AMDVLK ICD discovery, ROCm/OpenCL where present, and DMA-BUF/PRIME.
- PAL is a useful abstraction reference, but PAL internals are not a stable MVGAL backend ABI.
- AMD graphics aggregation must be implemented through Vulkan/OpenCL/SYCL/runtime layers, with conservative fallback.

## Intel media-driver

Source: <https://github.com/intel/media-driver>

Observed upstream characteristics:

- Intel media-driver is a VA-API user-mode driver focused on hardware decode, encode, and video post-processing.
- It installs `iHD_drv_video.so` and related media runtime components.
- It depends on LibVA/GmmLib and kernel support through i915/xe paths.
- Upstream documents supported generations through recent Intel graphics and distinguishes full-feature and free-kernel builds.

MVGAL implications:

- Model Intel media-driver as a media/offload backend, not as the primary graphics aggregation ABI.
- General graphics/compute integration should use DRM render nodes, Vulkan/ANV, OpenCL/SYCL, Level Zero, or other supported Intel compute paths.
- Media offload must report codec/build limitations explicitly.

## Moore Threads / MTT

Sources: <https://developer.mthreads.com/> and Moore Threads Linux driver docs/blog pages.

Observed public characteristics:

- Official docs expose MUSA SDK, MTML management library, performance tools, and cloud-native tooling.
- Public Linux documentation shows `mtgpu.ko` as a Moore Threads DRM driver with Dual MIT/GPL module metadata.
- The community repository named in the task is `https://github.com/dixyes/mtgpu-drv`, but MVGAL still needs a reproducible source/license/version audit before production claims.

MVGAL implications:

- Keep MTT support optional and capability-probed.
- Probe for DRM nodes, MUSA/MTML libraries, DMA-BUF/PRIME behavior, telemetry, and compiler/runtime availability at runtime.
- Degrade cleanly if any MTT component is absent or incompatible.

## Common Cross-Vendor Integration Points

| Domain | Portable MVGAL integration point | Non-portable / avoid as stable ABI |
|---|---|---|
| Discovery | PCI class/vendor/device, `/sys/class/drm`, DRM render nodes, Vulkan physical devices | Private vendor device databases |
| Memory sharing | DMA-BUF/PRIME, sync_file, explicit host staging | Assuming coherent cross-vendor VRAM |
| Submission | Vulkan/OpenCL/SYCL/CUDA/Level Zero user-space API layers | Rewriting native vendor command buffers in `mvgal.ko` |
| Sync | DMA fences, timeline semaphores, API fences/events | Private fence structures outside documented UAPI |
| Power/telemetry | sysfs/hwmon, vendor management libs through unprivileged queries | Privileged writes outside Polkit/pkexec policy |

## Implementation Rules

1. Single-GPU pass-through is the safe default.
2. Graphics aggregation requires API-level ownership of resources, fences, and presentation semantics.
3. Compute aggregation requires compatible kernels, explicit partitioning, and verified execution on more than one physical GPU.
4. DMA-BUF/P2P paths must be probed per pair of devices; topology heuristics are advisory only.
5. Public status docs must distinguish implemented, synthetic, hardware-validated, and design-only features.
