WikiBot: New page (2026-10-30 wiki refresh): Vulkan

2026-10-30T17:05:01Z

New page (2026-10-30 wiki refresh): Vulkan

New page

{{About message}}

= Vulkan =

<blockquote>'''Scope.''' How a stock guest Vulkan application runs on the emulated vGPU: the guest-side stack, the submit/completion path, and the honest state of the work — including the one thing every Vulkan run on the emulated vGPU currently has in common: '''the pipeline completes, and the frames are black'''. The shared host machinery is on [[Graphics Execution|<code>Graphics-Execution.md</code>]]; the CUDA compute chain (further along) is on [[The Execution Frontier|<code>Execution-Frontier.md</code>]]. Canonical sources: [https://git.vgpu.io/open-iov.git/tree/docs/04-implementation/04-real-render-walls.md <code>../docs/04-implementation/04-real-render-walls.md</code>] and [https://git.vgpu.io/open-iov.git/tree/docs/04-implementation/05-graphics-execution-plan.md <code>../docs/04-implementation/05-graphics-execution-plan.md</code>]; the docs tree wins on disagreement.</blockquote>

Status: 2026-10-30, tree <code>master @ b4930168</code>. Tags: <code>[live]</code> observed with the stock guest driver; <code>[wip]</code> partial; <code>[wall]</code> current blocker; <code>[target]</code> defined success state.

== 1. The guest Vulkan stack ==

A Vulkan application loads the '''loader''' (<code>libvulkan.so</code>), which dispatches to an '''installable client driver (ICD)''' — for NVIDIA GPUs, the NVIDIA Vulkan driver. On Linux, Vulkan compute does not require an X server; the display path does (through <code>nvidia-modeset</code>/DRM for presentation). The kernel-side requirements are the same as CUDA's: <code>nvidia.ko</code>, the GSP client, channels, memory objects and fences.

At device creation the driver also walks the '''display/modeset device''' allocation path (the <code>ALLOC_DEVICE</code> class family) — on a vGPU-style device the driver expects the host to provide those display classes, which the emulation must answer for <code>vkCreateDevice</code> to succeed. Past that gate, the driver behaves much like the compute stack: memory types through its VidHeap classes, queues as channels, and work as method streams.

== 2. The submit and completion path (observed) ==

[[File:Open-IOV-vulkan-submit-path.png|frameless|center|upright=2.2|One Vulkan queue submit end to end on the emulated vGPU.]]

<pre>app: vkQueueSubmit(fence)
-> NVIDIA driver: push buffer + GPFIFO entry + doorbell
-> vgsp.ko: capture section, translate to a vendor launch,
relocate operands into shadow pages, submit on a real channel
-> physical GPU: front-end fetch, engine executes, authors release
-> vgsp.ko: completion relay (MSI-X + poller) back to the guest
-> app: fence releases; frame readback proceeds
ASCII fallback above; the sequence shows one queue submit end to end.</pre>

Two mechanics make this work today: the emulation decodes the driver's compute-dispatch shape — a '''direct method stream''' (object bind, window runs, code runs, a subchannel data-port stream) with '''no inline launch descriptor''' — and ''translates'' it into a launch the real engine accepts, and it derives the submit's release groups from the driver's own push words so the fence value is released when the engine completes (the "fence fold": the pre-built GPFIFO continuation beyond the put pointer is swept and the submit's release groups are applied forward-only).

== 3. Status on the emulated vGPU ==

{| class="wikitable"
|-
! Item
! State
|-
| <code>vkCreateDevice</code> on the emulated vGPU (display/modeset allocation path answered)
| <code>[live]</code>
|-
| Full pipeline: instance, device, allocation, image/view/buffer/shader/descriptor, pipeline, command buffer, fence
| <code>[live]</code>
|-
| Queue submit, engine-side execution of the translated launch, fence release, frame readback
| <code>[live]</code>
|-
| The client saves frames end to end (<code>VKFRAME</code> evidence)
| <code>[live]</code>
|-
| Non-black frames
| <code>[wall]</code>
|-
| The driver's program (SASS) upload materialised by the emulation
| <code>[wall]</code>
|-
| The engine's page tables mapping the program VA
| <code>[wall]</code>
|}

== 4. Where the wall is, precisely ==

The client ''believes'' it uploaded its shader and dispatches with a valid program address, but the bytes never appear in any source the emulation can see: the driver delivers programmed SASS and descriptors through an '''MME program + inline-to-memory stream''' on its copy/utility channel, and the inline-data writes are not yet materialised for the graphics clients. Two coupled facts define the remaining work:

# '''Delivery''' — decode and execute the driver's inline upload so the program page becomes non-zero (the same machinery already works for CUDA's uploads; the graphics clients' shapes are the extension).
# '''Mapping''' — the engine's page tables must map the program VA. With the data-set gate bypassed, the engine fetches the launch and raises a real MMU fault (<code>FAULT_PDE</code>) at the program VA — proof the channel, context and fetch path are alive, and that mapping plus content is the missing pair.

When both land, the emulated vGPU should carry its first non-black Vulkan frame — the milestone the whole graphics effort is converging on ([[Graphics Execution|<code>Graphics-Execution.md</code>]] §6).

== 5. What this page is not claiming ==

* No rendered pixels yet — every frame saved so far is black.
* No performance numbers.
* <code>vkCreateDevice</code> success does not imply rendering; it means the device model answers the driver's device-view correctly.

== 6. Related pages ==

* [[Graphics Execution|<code>Graphics-Execution.md</code>]] — the shared lanes, the <code>0xC597</code> graphics stream and the ranked walls.
* [[OpenGL|<code>OpenGL.md</code>]] — the GL path through the X server.
* [[DirectX|<code>DirectX.md</code>]] — the Windows/DirectX target.
* [[CUDA Userspace Driver|<code>CUDA-Userspace-Driver.md</code>]] — the userspace driver model the Vulkan ICD mirrors in structure.
* [[Introduction to GMMU|<code>Introduction-to-GMMU.md</code>]] — translation and the engines.
* [https://git.vgpu.io/open-iov.git/tree/docs/04-implementation/04-real-render-walls.md <code>../docs/04-implementation/04-real-render-walls.md</code>] — the measured wall ledger, with every experiment and its verdict.

Vulkan - Revision history

WikiBot: New page (2026-10-30 wiki refresh): Vulkan