b-bridge - out-of-process Direct3D 9 rendering

b-bridge: out-of-process Direct3D 9 rendering for GTA IV: The Complete Edition

A research release. Fork of NVIDIA's bridge-remix. Source, issues and releases: github.com/gutbash/b-bridge

Explainer

9QZ2xTVJpNg

Abstract

GTA IV is a 32-bit process. Every resource the graphics driver allocates on the game's behalf (textures, shadow maps, render targets, staging buffers) is mapped into the same 4 GB address space as the game's own data, and a heavily modded install exhausts that space long before it exhausts RAM or VRAM. b-bridge moves the entire Direct3D 9 device into a separate 64-bit process. The game keeps a thin 32-bit d3d9.dll that forwards every call over a shared-memory channel to a 64-bit server, which renders through DXVK on Vulkan. On the test system this returned about 880 MB of address space to the game and held frame time at parity with in-process DXVK, allowing a 5 GB texture-pack stack to run where the same install previously crashed within minutes.

Problem

The address-space wall, not memory, is the practical ceiling on GTA IV modding. Large-address-aware flags, streaming-budget tuning, the -nomemrestrict family and texture-memory caps in DXVK reduce pressure but cannot change the fact that driver allocations and game allocations share one 32-bit space. Measured on the reference install before this work: largest contiguous free region as low as 5 MB with view distance at 100, and a streaming-allocator crash band at 2. 8 to 3. 0 GB committed.

Method

The IPC layer of NVIDIA RTX Remix already marshals D3D9 across processes; its purpose there is to feed a path tracer. b-bridge keeps the transport and discards the renderer: the server loads an unmodified DXVK 3. 0. 2 instead of the Remix runtime, and the client is tuned for a game that issues 15,000 to 70,000 D3D9 calls per frame.

Changes against upstream:

• []Client frame pacer (waitable timer plus spin), so pacing happens in the game process rather than the server. bridge.conf: clientFrameCap[/]

  []State-block transfer plans: precomputed dirty index lists for the D3DSBT_ALL blocks GTA IV applies about 475 times per frame[/]

  []StateBatch: render, sampler and stage state, textures, shaders, streams and shader constants packed into one record per flush. bridge.conf: clientStateBatch[/]

  []Batched command index publish. bridge.conf: clientCmdPublishBatch[/]

  []Merged device/channel lock; import-free spinlock, so ASI loaders that hook kernel32 cannot re-enter it[/]

  []Per-window wait statistics in bridge32.log; assert logger no longer dereferences a dead channel[/]

  []Server: StateBatch replay; vanilla-DXVK mode as the supported configuration; responses only for calls that return data[/]

  Results

  Reference system: Intel i7-9700K, NVIDIA GeForce RTX 2070 (8 GB), driver 610. 74, 2560x1440 borderless, GTA IV CE 1. 2. 0. 59 with FusionFix. Frame times are means over a fixed 60-second scripted drive, uncapped. Memory figures are from an in-process address-space monitor at view and detail distance 100.

  • []In-process DXVK, same route (6 runs): 16. 9 ms. Largest free region at view 100: 5 MB[/]

    []b-bridge, upstream client (5 runs): 22. 4 ms. About 800 MB[/]

    []b-bridge, transfer plans + responses off (4 runs): 18. 6 ms. About 800 MB[/]

    []b-bridge, final client (5 runs): 13. 6 ms. About 800 MB[/]

    []b-bridge, final client, 5 GB texture-pack stack: 16. 4 ms. 735 to 819 MB[/]

  The batching work is what brings the bridged frame time below the in-process figure; the transport itself costs time, and the client hides it by sending fewer, larger messages. The five figures in the Images tab show the per-stage frame time, the frame-time distribution, the address-space comparison, the cost of a content and post-processing stack, and GPU utilisation through a session.

  Limitations

  These are the boundaries of what was tested. Nothing outside them should be assumed to work.

  []Measured on NVIDIA only. Every number above was taken on one RTX 2070 with one driver version. Users have since run the build on AMD (Radeon 680M, RDNA2, Windows 11) and on Intel Arc B580 under Linux with Proton and Mesa ANV. Those are reports that it runs, not measurements: no frame-time or address-space figures exist from either system.[/]

  []One machine, one configuration. One CPU, one resolution and refresh rate, borderless windowed only. Exclusive fullscreen is disabled by the shipped dxvk.conf because the mode switch loses the device across the process boundary.[/]