Video summary
Видеокарта NVidia в Эльбрусе
Main summary
Key takeaways
Core topic
The video demonstrates and explains how NVIDIA GPUs can (partially) work on the Elbrus architecture (MCST Elbrus), which uses its own E2K architecture and a different hardware/software initialization path than typical x86 systems.
The speaker argues that Elbrus is not “plug-and-play” for graphics hardware: getting graphics working is described as a constant engineering effort.
Key technological claim: why NVIDIA usually doesn’t work on Elbrus
- NVIDIA cards require an x86-compatible initialization flow.
- During power-on, NVIDIA GPUs attempt to run x86 code as part of initialization.
- Because Elbrus doesn’t have an x86 CPU, the NVIDIA card cannot initialize under normal conditions.
- In contrast, AMD GPUs are said to work because their open/alternative driver paths on Elbrus don’t depend on the same x86 initialization approach.
Driver situation (proprietary vs open)
- NVIDIA proprietary (closed) drivers work very well on Linux, but:
- the source code is unavailable, and
- there’s no guarantee they adapt cleanly to non-x86 architectures.
- An open source driver (“nou”, noted as slow) exists but:
- lacks the required initialization process, and
- provides only partial/limited acceleration.
What the presenter previously achieved (RTX on Elbrus, limited performance)
Earlier in the video (historical context):
- They tested with AMD cards:
- RX 570 first
- then AMD Vega 64
- For an RTX-focused experiment, they used an AMD “Radeon 6700 series”-class card and ran Half-Life with ray tracing (an “RTX” reference via a fan/ported ray-tracing approach).
- Performance was limited:
- about 30 FPS in simple scenes
- 10–12 FPS in more complex scenes
- Even so, the claim is that they were among the first to successfully run this kind of RTX experiment on Elbrus.
New development in this video: an NVIDIA driver for Elbrus
The “why now” described in this video:
- In 2022, there was a large leak of NVIDIA-related source code from NVIDIA servers (including proprietary driver source).
- The video claims an anonymous contributor (via contact at MCST) used those leaked texts to create an Elbrus-targeted NVIDIA driver.
- The intended GPU range is roughly estimated as up to RTX 2000-era (speaker’s estimate).
- They obtain/try to install this driver on Elbrus.
Hardware test setup (current video)
Main system used:
- Elbrus 8SV CPU (~1,550 MHz noted)
- 2×32 GB DDR4 ECC
- Initial NVIDIA target: GeForce RTX 2060 Super
- AMD comparison card(s): Radeon RX 6700 XT, later another AMD GPU model.
Important boot/visual behavior
- Elbrus BIOS/boot may initially “see” the integrated onboard GPU first.
- To observe full initialization:
- they use two monitors
- one connected to the integrated GPU
- one connected to the discrete AMD/NVIDIA GPU
- they use two monitors
- The discrete GPU display becomes visible only after the correct initialization/driver phase begins:
- AMD succeeded more naturally
- NVIDIA required the new driver
Tutorial/step-by-step: installing the NVIDIA driver on Elbrus
The presenter describes a practical procedure and debugging workflow:
- Boot/install Elbrus OS
- They even reinstall to avoid prior configuration issues.
- SSH into the system
- Because the discrete GPU monitor stays dark while it can’t initialize.
- Copy the NVIDIA driver package to the system.
- Run the installer
- Installation fails during kernel module build due to mismatch/compatibility with the kernel environment (an “UVM”/module-related issue is mentioned).
- Manual patching (“hacking”) of driver source contents before rebuilding modules:
- unpack the driver archive manually
- edit specific definitions related to features/affinity flags (example edits described by modifying an affinity-supported macro)
- edit kernel/CPU mask-related code sections to align with Elbrus kernel expectations
- Re-run module build/install steps.
- Verify:
- system modules such as nvidia DRM / nvidia modeset appear
- X starts successfully and displays NVIDIA output
Result
- They conclude: “The Nvidia graphics card in Elbrus is working” (at least for display and X integration).
What they tested after success (games/demos)
The video emphasizes “it works” and provides software success cases:
- Half-Life / Half-Life 2
- earlier AMD path; later NVIDIA RTX demos are emphasized more.
- Quake 2 RTX
- tested first with an AMD “new” GPU
- contrasted with NVIDIA RTX behavior historically
- described as smoother/working on the newer AMD card in this setup.
- Unreal Engine 5 technical demo
- shows UE5 ported/rendered on Elbrus using a Vulkan/related pipeline.
- The Witcher 3
- described as a complex Elbrus port
- performance around console-level (~30 FPS) with tuning and vertical sync considerations
- technical notes:
- DX → Vulkan translation
- some physics may run on the CPU rather than the GPU due to pipeline limitations.
- Real-time demos / game examples
- Unreal Tournament 4 mentioned as running after full load.
They explicitly avoid deep benchmarking at first, because MCST suggested waiting for a newer driver version.
Final conclusions/analysis points
- Primary achievement: achieving NVIDIA display output on Elbrus despite Elbrus being “incompatible” by default for NVIDIA initialization needs.
- Comparisons are framed as tricky:
- NVIDIA driver is considered older / not fully optimized yet,
- so direct benchmarking vs AMD may be misleading.
- They also discuss that future updates could add support for newer GPUs and improve performance.
Main speakers / sources
- Main speaker: the YouTube channel host/presenter (first-person narration; no name provided in subtitles).
- Referenced external entities:
- MCST (engineers and the contact mentioned)
- NVIDIA (drivers; leak context)
- Anonymous driver contributor (identity unknown; credited with creating the Elbrus NVIDIA driver based on leaked code)
- Timofey (credited with porting Witcher 3 to Elbrus)