CheeseBridge is an experimental research component for MacNCheese.
It is not a production backend, not a replacement for the current MacNCheese Wine path, and not intended for real game support yet. The first goal is to prove that a Linux guest can send Vulkan-like work to a macOS host process and receive correct responses.
The default CMake build creates the first fake bridge prototype:
cmake -S . -B build
cmake --build buildRun the fake host in one terminal:
build/demo/cheesebridge_fake_host tcp:127.0.0.1:43210Run the guest demo in another terminal:
build/demo/cheesebridge_guest_demo tcp:127.0.0.1:43210The guest sends HELLO, CAPABILITY_QUERY, CREATE_INSTANCE, ENUMERATE_PHYSICAL_DEVICES, CREATE_DEVICE, CREATE_BUFFER, QUEUE_SUBMIT, and PRESENT messages. The host logs each request and replies with placeholder ids. This phase intentionally does not require MoltenVK, Metal, Vulkan headers, Wine, DXVK, or a VM.
The Linux guest ICD can now run as a local stub when no macOS host endpoint is configured. This is the Phase 2 path for loader discovery and vulkaninfo smoke tests inside the Linux guest:
cmake -S . -B build-guest -DCHEESEBRIDGE_BUILD_GUEST=ON -DCHEESEBRIDGE_BUILD_DEMO=OFF
cmake --build build-guest
VK_DRIVER_FILES=$PWD/build-guest/guest/cheesebridge_icd.dev.json CHEESEBRIDGE_LOG=info vulkaninfo --summaryBy default the ICD uses the local stub backend unless CHEESEBRIDGE_HOST is set. To force the network forwarding path later:
CHEESEBRIDGE_STUB=0 CHEESEBRIDGE_HOST=tcp:127.0.0.1:43210 vulkaninfo --summaryThe stub reports one integrated GPU named CheeseBridge Vulkan ICD Stub and answers the basic instance, physical device, memory, queue-family, and device creation queries expected during early loader probing.
After the Phase 4 triangle renders through cheesebridge_host, the next target is a tiny Direct3D 11 app running through Wine + DXVK inside the Linux guest.
Start the macOS CheeseBridge host in one terminal:
build/host/cheesebridge_host 43210Install the guest ICD and demo payloads into the bottle:
build/hase/hasectl start test
build/hase/hasectl install-fex test
build/hase/hasectl install-icd testinstall-fex installs FEX from the FEX-Emu Ubuntu PPA, downloads an Ubuntu 24.04 x86_64 rootfs with FEXRootFSFetcher, and stores the FEX state in /mnt/hase/fex. install-icd also cross-compiles demo/d3d11_smoke.c into /mnt/hase/vulkan/icd.d/d3d11-smoke.exe inside the VM. Prepare the Wine/DXVK prefix:
build/hase/hasectl prepare-dxvk-smoke testThen run the smoke:
build/hase/hasectl run-dxvk-smoke testThe default HaSe bottle is ARM64-only and uses FEXBash for x86_64 execution. prepare-dxvk-smoke and run-dxvk-smoke run the FEX installer automatically if FEX is missing. The next required runtime piece is an x86_64 Wine or Proton environment inside the FEX rootfs; the old x86_64 Lima/Rosetta smoke path has been removed.
DXVK install sources are tried in this order: HASE_DXVK_DIR, a dxvk-*.tar.* archive placed in /mnt/hase/proton, then winetricks -q dxvk.
Steam itself stays on Lavapipe for the Linux UI. hasectl steam now starts the CheeseBridge host and a VM-side Proton bridge daemon. The daemon watches Steam's installed Proton runtimes and wraps their proton launchers so Windows games launched from Steam inherit the CheeseBridge Vulkan environment automatically.
Because HaSe runs Windows games as x86_64 processes under FEX, hasectl install-icd installs two guest ICD builds: a native ARM64 ICD for VM-side Vulkan tools and an x86_64 ICD for Proton/DXVK. Proton game launches prefer /mnt/hase/vulkan/icd.d/cheesebridge_icd.x86_64.json.
build/hase/hasectl steam testYou can also start or refresh only the game bridge:
build/hase/hasectl game-bridge testFor native Linux Vulkan games that do not use Proton, this manual per-game launch option remains available:
/mnt/hase/runtime/cheesebridge-game.sh %command%Both paths override VK_DRIVER_FILES and VK_ICD_FILENAMES for the game process, point CHEESEBRIDGE_HOST at tcp:host.lima.internal:43210, and map normal Linux VK_KHR_xlib_surface / VK_KHR_xcb_surface creation to a host-owned CheeseBridge Metal window. Steam login, library UI, and launchers still use the cropped X11 framebuffer path.
HaSe is the runtime manager. CheeseBridge is only the Vulkan graphics bridge. The first implementation is a Lima-backed bottle manager that creates a hidden Linux VM shape with a minimal X11 session for Steam, launchers, and installer UI.
Install Lima first:
scripts/install-limactl.shBuild it with the default CMake build:
cmake -S . -B build
cmake --build buildCreate a bottle:
build/hase/hasectl init testThis creates:
HaSe bottle
home/
steam/
proton/
wine-prefixes/default/
fex/
vulkan/icd.d/
shared/
metadata/
vm/lima.yaml
runtime/
windows/
Start the VM and hidden graphical session:
build/hase/hasectl start testFirst boot downloads the Ubuntu ARM64 image and installs the minimal X11 tooling, so it can take a few minutes. HaSe disables Lima containerd for new bottles because the VM is used as a managed Linux runtime, not as a container host. New Lima bottles default to 6 vCPUs, 8 GiB RAM, and a 48 GiB disk because Linux Steam under FEX can kill/restart Steam webhelper when memory is tight.
Useful prototype commands:
build/hase/hasectl status test
build/hase/hasectl shell test
build/hase/hasectl install-fex test
build/hase/hasectl install-steam test
build/hase/hasectl steam test
build/hase/hasectl game-bridge test
build/hase/hasectl demo-window test
build/hase/hasectl windows test
build/hase/hasectl stop testThe Steam command launches the Linux Steam bootstrapper through FEX, not Windows Steam through Wine. The generated Linux runtime uses Xvfb plus a tiny window manager on display :99, with a black background and no desktop shell. The experimental fast path defaults to a smaller 960x540x24 guest display, raw XWD frame capture at about 30 fps, Steam CEF GPU-disable flags for the UI, and a shared input queue to avoid per-event SSH. Override with HASE_GEOMETRY, HASE_STEAM_ARGS, HASE_CAPTURE_DELAY, HASE_CAPTURE_FORMAT, HASE_INPUT_DELAY, HASE_HOST_REFRESH_INTERVAL, or HASE_WINDOW_RELIST_INTERVAL when testing.
On macOS, the default build also creates the first host-side window bridge:
build/hase/hasectl start test
build/hase/hasectl demo-window test
build/hase/hase_window_host --list test
build/hase/hase_window_host testhase_window_host opens a native macOS window, polls the hidden Linux X11 session through limactl, captures the selected X11 window as PNG frames, and displays them in Cocoa. Basic mouse, scroll, and keyboard input is mapped back into the Linux X11 window through xdotool. Pass a specific Linux window ID from --list to attach to a particular window:
build/hase/hase_window_host test 0x0060001bThis is intentionally a first cropped-framebuffer host path for Steam/login/launcher UI. High-performance game rendering still belongs to CheeseBridge Vulkan presentation later.
HaSe is an experimental MacNCheese backend designed for a future where relying on Rosetta 2 may not be enough.
Instead of running the full compatibility stack directly through macOS Wine, HaSe uses a small ARM64 Linux environment. Inside that guest, FEX, Wine, DXVK, and VKD3D-Proton can run in a Proton-like stack.
The hard part is graphics acceleration.
CheeseBridge (still a concept (gonna be really complicated making this but possible)) exists to make the Linux guest believe it has a Vulkan-capable GPU while the macOS host performs the actual rendering through MoltenVK or a native Metal backend.
Windows x86_64 game
↓
FEX-Emu
↓
Wine / Proton-style runtime
↓
DXVK / VKD3D-Proton
↓
Guest Vulkan loader
↓
CheeseBridge Vulkan ICD
↓
CheeseBridge guest protocol layer
↓
VM communication layer
↓
CheeseBridge host on macOS
↓
MoltenVK or custom Metal backend
↓
Metal
↓
Apple GPU
DXVK and VKD3D-Proton already translate DirectX workloads into Vulkan.
That means HaSe does not need to start by implementing DirectX handling. Wine, DXVK, and VKD3D-Proton already cover that layer.
The main problem becomes this:
How can Vulkan inside a Linux guest render using the macOS host GPU?
CheeseBridge is the proposed answer to that problem.
CheeseBridge is a virtual Vulkan bridge with two sides.
The guest side runs inside the Linux VM. It presents itself as a Vulkan driver or Vulkan ICD, receives Vulkan calls from DXVK or VKD3D-Proton, serializes those calls, and sends them across the VM boundary.
The host side runs on macOS. It receives the serialized commands, recreates or translates the requested work, executes it through MoltenVK or Metal, and presents the final frame on macOS.
Game makes a DirectX call
↓
DXVK converts it to Vulkan
↓
Guest Vulkan ICD receives the Vulkan command
↓
CheeseBridge serializes the command
↓
Command crosses the VM boundary
↓
macOS host receives the command
↓
Host executes through MoltenVK or Metal
↓
Frame appears on screen
MoltenVK by itself is not enough.
MoltenVK is a Vulkan implementation for macOS that runs over Metal. The Linux guest cannot directly use MoltenVK because MoltenVK runs on the macOS host, not inside the Linux VM.
CheeseBridge needs to provide the missing path:
Guest Vulkan API
↓
Bridge protocol
↓
Host Vulkan or Metal backend
The concept is similar to Vulkan forwarding designs such as Venus and virtio-gpu, where commands from a guest are forwarded to a renderer on the host.
Inside Linux, applications usually do not call the GPU driver directly. They call the Vulkan loader first.
DXVK and VKD3D-Proton call Vulkan functions through the loader. The loader then discovers and loads an ICD.
ICD means Installable Client Driver.
For HaSe, CheeseBridge needs a custom Vulkan ICD inside the Linux guest. This ICD is responsible for exposing Vulkan entry points and connecting those calls to the CheeseBridge guest protocol layer.
Early target entry points may include:
vkGetInstanceProcAddr
vkGetDeviceProcAddr
vkCreateInstance
vkEnumeratePhysicalDevices
vkCreateDevice
vkCreateBuffer
vkCreateImage
vkQueueSubmit
vkQueuePresentKHR
The first ICD does not need full Vulkan support. It can start as a stub that loads through the Vulkan loader, logs calls, connects to the host, and returns controlled fake device information.
The protocol is the communication format between the Linux guest and the macOS host.
Early prototypes can use JSON or simple structs (this is what macndcheese uses for backend communication with the frontend app). Later versions should move to a binary protocol with shared memory for performance.
Initial message types:
HELLO
HELLO_REPLY
CAPABILITY_QUERY
CAPABILITY_REPLY
CREATE_INSTANCE
CREATE_INSTANCE_REPLY
ENUMERATE_PHYSICAL_DEVICES
PHYSICAL_DEVICES_REPLY
CREATE_DEVICE
CREATE_DEVICE_REPLY
CREATE_BUFFER
CREATE_BUFFER_REPLY
CREATE_IMAGE
CREATE_IMAGE_REPLY
CREATE_SHADER_MODULE
QUEUE_SUBMIT
QUEUE_SUBMIT_REPLY
PRESENT
PRESENT_REPLY
DESTROY_RESOURCE
The host renderer runs on macOS and executes work requested by the guest.
There are three possible backend paths.
Option A is MoltenVK. Guest Vulkan commands are reconstructed on the host and passed into MoltenVK. This is the best first target because shader translation and Vulkan-to-Metal behavior already exist there.
Option B is a custom Metal backend. This could be faster later, but it is much harder because it requires direct handling of Vulkan concepts, shader translation, pipeline state, synchronization, memory, and presentation.
Option C is a hybrid model. CheeseBridge starts with MoltenVK and later replaces selected performance-critical paths with native Metal code.
The recommended first backend is MoltenVK.
Graphics forwarding is not only about commands. It is also about memory.
CheeseBridge must handle guest memory, host memory, GPU-visible memory, and the VM boundary between them.
Required areas include:
Buffer creation
Image and texture creation
Memory allocation
Memory mapping
Resource lifetime
Host and guest copies
Shared memory
GPU fences
Semaphores
Synchronization objects
Apple Silicon unified memory helps, but it does not remove the VM boundary. Guest memory and host memory still need to be mapped, copied, or shared correctly.
Vulkan synchronization is strict and central to correctness.
CheeseBridge will eventually need support for:
Fences
Binary semaphores
Timeline semaphores
Queue submissions
Image layout transitions
Swapchain timing
Present synchronization
Broken synchronization can create failures that are difficult to debug. Symptoms may include flickering, corrupted frames, random freezes, crashes, or rendering bugs that only appear sometimes.
DXVK and VKD3D-Proton generate shaders for Vulkan.
CheeseBridge must pass shader modules to the macOS host. If the host backend uses MoltenVK, MoltenVK can handle the Vulkan shader path toward Metal execution.
A custom Metal backend would make shader handling much harder and should not be part of the first implementation.
Games render to a Vulkan swapchain.
Inside the Linux guest, DXVK expects a Vulkan swapchain. The final window, however, must exist on macOS.
A possible presentation model:
Guest creates a fake Vulkan swapchain
↓
Guest renders to virtual swapchain images
↓
Host maps or copies those images into Metal textures
↓
Host presents through a macOS window owned by MacNCheese
Presentation should be treated as a separate milestone. It is not required for the first fake bridge prototype.
CheeseBridge needs a communication layer between the Linux guest and the macOS host.
The first implementation should use the simplest transport that proves the architecture. Performance can come later.
Possible transports:
TCP localhost socket (My idea)
Unix socket
virtio-vsock
Shared memory
Custom virtio device
Recommended path:
Start with sockets
Add structured protocol handling
Move high-volume data to shared memory
Consider virtio-vsock or a custom virtio device later
HaSe is the runtime manager. CheeseBridge is only the graphics bridge.
A HaSe bottle should be treated as a managed Linux bottle. It contains the Linux userspace, runtime configuration, FEX configuration, Steam or Proton installation, Wine prefix data, Vulkan ICD configuration, shared folders, and per-bottle launch metadata.
The first user-visible goal is not a full Linux desktop. The goal is a CrossOver-style experience where Steam and games appear as normal macOS windows while the Linux environment stays hidden.
The technical requirement is still a Linux kernel. macOS cannot run Linux binaries or Linux containers directly without a Linux kernel underneath. A Docker-style design does not remove this requirement on macOS, because Docker Desktop also runs Linux containers inside a hidden Linux VM.
The first backend should use a small hidden Linux VM. Lima is a good prototype backend because it can manage Linux VM creation, boot, SSH access, file sharing, and port forwarding with less custom code. HaSe can later replace Lima with a native backend built on Apple Virtualization.framework, QEMU, or a custom VM manager.
The VM should not boot into GNOME, KDE, or a normal desktop session. It should boot into a minimal graphical session with only the services needed for Steam, launchers, input, audio, file access, and window tracking.
A useful first layout is:
HaSe bottle
rootfs or VM image
home directory
Steam data
Proton runtime
Wine prefixes
FEX rootfs and configuration
Vulkan loader configuration
CheeseBridge ICD
shared folders
launch metadata
window metadata
The macOS side should own the visible user experience. HaSe should create the macOS windows, manage their position and size, start and stop the Linux runtime, and connect each visible window to the correct Linux window or game swapchain.
Steam should be allowed to appear. Users expect Steam login, library management, downloads, cloud saves, controller settings, game properties, and Proton selection. HaSe should not require users to launch games only from a custom HaSe library. The correct model is that Steam can appear as a normal macOS window, and games launched from Steam can open as their own macOS windows.
The simplest first implementation can use a cropped framebuffer model.
Linux graphical session
↓
Black background
↓
Steam opens a normal Linux window
↓
HaSe tracks the Steam window rectangle
↓
HaSe crops that region from the VM display
↓
HaSe presents the crop inside a macOS NSWindow
The same idea can be used for child windows:
Steam login window
Steam main window
Game launcher
Game window
Popup menu
File picker
Settings dialog
Each Linux window can become a separate macOS window by tracking its geometry and cropping the correct region from the VM framebuffer. This gives a rootless-window feel without building a full Wayland-to-Cocoa compositor in the first version.
The Linux background should be black or otherwise neutral. No taskbar, panel, dock, wallpaper, desktop icons, or visible system UI should be shown. If the cropped region is correct, the user should only see the selected app window.
Input must be translated back into Linux coordinates.
macOS window receives mouse event at local position
↓
HaSe converts local position to Linux display coordinates
↓
HaSe sends mouse event into the VM
↓
Linux app receives the event as if it happened inside its own window
Keyboard input needs the same treatment. HaSe should forward key down, key up, text input, modifier state, focus changes, and shortcut handling. Some shortcuts should remain macOS shortcuts. Others must be delivered to Linux. This needs explicit policy because games, Steam, and launchers expect different behavior.
Window resizing should be handled in both directions.
Linux app resizes itself
↓
HaSe resizes the macOS window
macOS user resizes the window
↓
HaSe requests a Linux window resize
↓
Linux app redraws
↓
HaSe updates the crop
Menus, dropdowns, and tooltips are important. Many toolkits create them as separate temporary windows. HaSe should detect those windows and either attach them to the parent macOS window or expose them as borderless child NSWindows positioned above the parent.
Fullscreen games need a separate path. A game that uses Vulkan through DXVK or VKD3D-Proton should eventually present through CheeseBridge instead of the cropped VM framebuffer. The cropped framebuffer path is useful for Steam, launchers, installers, login dialogs, and non-accelerated UI. The CheeseBridge path is for high-performance game rendering.
The long-term display model should have two paths.
Steam and launcher UI
↓
Linux window system
↓
HaSe window management
↓
macOS NSWindow
Game rendering
↓
DXVK or VKD3D-Proton
↓
Vulkan
↓
CheeseBridge
↓
macOS Metal window
The cropped framebuffer path can be the first working version. A later version can replace parts of it with a real rootless window bridge that maps Wayland or X11 surfaces more directly into macOS windows. For the first prototype, the Linux side can use X11 with a tiny window manager because X11 window geometry and reparenting behavior are easier to inspect. A later Wayland path can use a small custom compositor if needed. The compositor or window manager should expose window IDs, titles, positions, sizes, focus state, stacking order, and parent-child relationships to HaSe.
HaSe should keep a window table on the macOS side.
linux_window_id
macos_window_id
title
process_id
x
y
width
height
visible
focused
parent_window_id
surface_type
uses_cheesebridge
This table lets HaSe decide whether a window is a normal UI window, a Steam window, a launcher window, a popup, or a game render surface.
The first implementation does not need perfect rootless windows. It needs stable window tracking, correct input mapping, correct cropping, and acceptable behavior for Steam login and launching one simple game.
Audio, Clipboard, and File Sharing
Audio should be handled separately from window management. The first path can use PulseAudio or PipeWire inside the Linux guest and forward audio to a macOS host helper. This does not need to be solved by CheeseBridge.
Clipboard support should be explicit. HaSe should sync text clipboard data between macOS and the Linux guest. File drag and drop can come later.
File sharing should be mounted into the Linux environment. The bottle needs access to selected macOS folders, Steam library paths, downloads, and per-bottle storage. The first Lima-based version can use Lima file sharing. A later native VM backend can use VirtioFS or another shared filesystem.
The launch sequence should be deterministic.
User opens HaSe bottle
↓
HaSe starts hidden Linux VM if needed
↓
HaSe starts CheeseBridge host
↓
HaSe starts window capture and input bridge
↓
HaSe starts Linux graphical session
↓
HaSe launches Steam or selected app
↓
Steam window appears as macOS window
↓
User launches game from Steam
↓
Game window appears as macOS window
## Stop Sequence
The stop sequence should also be controlled.
User closes Steam or bottle
↓
HaSe asks Linux apps to exit
↓
HaSe waits for Steam and game processes
↓
HaSe shuts down CheeseBridge connections
↓
HaSe stops capture and input bridge
↓
HaSe suspends or shuts down the Linux VM
The first goal is not to make the VM disappear technically. The first goal is to make the VM disappear from the user experience.
Goal:
Write the design down, define the rough protocol, and agree on the scope before touching real Vulkan forwarding.
Success condition:
The project has a clear direction and the first implementation target is understood.
Goal:
Create a guest demo program that sends fake Vulkan-like messages to a macOS host process.
Example flow:
Guest sends CREATE_INSTANCE
Host replies OK
Guest sends CREATE_BUFFER
Host replies BUFFER_ID=1
Guest sends QUEUE_SUBMIT
Host logs the submit and replies OK
Success condition:
Guest and host can communicate reliably.
Goal:
Create a minimal Linux Vulkan ICD stub.
The ICD should load through the Vulkan loader, log function calls, respond to basic instance and device queries, connect to the CheeseBridge host, and return fake device information.
Success condition:
vulkaninfo can detect the CheeseBridge ICD or fail with useful logs.
Goal:
Forward a tiny Vulkan subset to the macOS host.
Target workloads:
Clear screen
Draw triangle
Basic vkcube-style test
Success condition:
A simple rendered frame appears on macOS.
Goal:
Execute reconstructed Vulkan work through MoltenVK on macOS.
Success condition:
The host can create buffers, images, command buffers, and present frames through the MoltenVK path.
Goal:
Run a very small DirectX application through Wine and DXVK inside the guest.(The linux enviroment)
Success condition:
The DirectX application creates a Vulkan device through CheeseBridge and reaches the host renderer.
Goal:
Run a lightweight Windows game.
Good early targets:
Small indie game
Old DirectX 9 game
Simple DirectX 11 Unity game
Simple demo application with predictable rendering
Targets to avoid at this stage:
Anti-cheat games
Heavy DirectX 12 games
Large launchers
AAA games
Games with complex DRM or online services
Protocol version: 0.1
Guest sends:
type: HELLO
protocol_version: 0.1
guest_name: CheeseBridgeGuest
features_requested:
- vulkan_basic
- shared_memory_optionalHost replies:
type: HELLO_REPLY
protocol_version: 0.1
status: OK
host_name: CheeseBridgeHost
features_supported:
- vulkan_basic
- moltenvk_backend_placeholderGuest sends:
type: CAPABILITY_QUERYHost replies:
type: CAPABILITY_REPLY
api: Vulkan
backend: MoltenVK
max_buffers: placeholder
max_images: placeholder
supports_present: falseGuest sends:
type: CREATE_INSTANCE
application_name: test
api_version: 1.2Host replies:
type: CREATE_INSTANCE_REPLY
status: OK
instance_id: 1Guest sends:
type: ENUMERATE_PHYSICAL_DEVICES
instance_id: 1Host replies:
type: PHYSICAL_DEVICES_REPLY
devices:
- device_id: 1
name: Apple GPU via CheeseBridge
type: integrated_gpuGuest sends:
type: CREATE_DEVICE
physical_device_id: 1
requested_queues:
- graphics
- presentHost replies:
type: CREATE_DEVICE_REPLY
status: OK
device_id: 1Guest sends:
type: CREATE_BUFFER
device_id: 1
size: 1048576
usage: vertex_bufferHost replies:
type: CREATE_BUFFER_REPLY
status: OK
buffer_id: 1Guest sends:
type: QUEUE_SUBMIT
device_id: 1
queue: graphics
commands:
- placeholder_command_buffer_id: 1Host replies:
type: QUEUE_SUBMIT_REPLY
status: OK
fence_id: 1Guest sends:
type: PRESENT
swapchain_id: 1
image_id: 1Host replies:
type: PRESENT_REPLY
status: OKCheeseBridge should not start with full DXVK support. (This is for future possible contributors)
It should not start with AAA games, heavy DirectX 12 workloads, anti-cheat titles, launchers, or custom Metal translation.
It should not replace the current MacNCheese backend until the bridge proves basic correctness.
It should not bundle proprietary Apple components.
It should not be presented as production-ready.
The first useful prototype should prove only this:
Linux guest or guest-like demo app
↓
Sends fake Vulkan messages
↓
macOS CheeseBridge host receives them
↓
Host logs them
↓
Host replies correctly
After that, the project can move to:
Vulkan ICD stub
↓ (I love these arrows)
vulkaninfo detection
↓
Fake device enumeration
↓
Basic command forwarding
↓
Simple rendered frame
Long term, MacNCheese could support more than one compatibility mode.
Native MacNCheese mode:
Wine 11.0
D3DMetal, DXMT, or macOS Vulkan paths
macOS-native execution where possible
HaSe mode:
Linux guest
FEX
Wine
DXVK / VKD3D-Proton
CheeseBridge
MoltenVK / Metal
HaSe is a research path for future compatibility and post-Rosetta planning. It is not the main backend today.
CheeseBridge is the graphics bridge required for HaSe to become useful.
Its job is to act like a virtual Vulkan GPU path:
Guest Vulkan ICD
↓
Command serialization
↓
VM transport
↓
Host renderer
↓
MoltenVK or Metal
The correct development path is incremental:
Fake bridge demo
Vulkan ICD stub
vulkaninfo detection
Simple triangle
MoltenVK host backend
DXVK smoke test
Small game
Performance work
The goal is not to build the full system at once.
The goal is to prove one layer at a time.
ALSO prs or first changes are WELCOME . Thanks.