BZLZHH 3a2555805a [Perf] (P12): the create window lands as the default - declared-answer retention replaces the ring, and the load frame goes 28.66 s -> 16.52 s (11.02 s at window 4)
The three things that made the deferral inert are all fixed, in the order they were
found: the reply ring could not hold an answer across the ~1,000 records between two
creates; a residency budget could not help because what displaces an answer is what
the SERVER sends, not what the client emits; and so the mechanism had to be retention.

WHAT LANDED
  * ILink::DeclareReplyRead + LinkCapabilities::RetainsReplies. The wire declares a
    seq will be read BEFORE it publishes, so the declaration cannot race its own
    answer; a link with the capability false ignores it, and the window does not
    defer on one (CreateWindowEffective() is gated on it).
  * StreamLink's ring of the last 8 answers becomes a declared-answer store: a
    monotone whitelist plus a cursor, answers kept until their reader TAKES them
    (take-and-delete under one lock, bytes swapped into the scratch), and a capacity
    of 24 that is FATAL to exceed rather than evicting. An evicted wanted answer is
    unrecoverable - re-latching by sending another create wipes the server's record
    (PipeApply.cpp:2033) and its PendingUploads (PipeApply.h:332) while the client
    cleared its dirty flags at emission (PipeApply.h:298-304) - so the capacity is
    sized so it cannot be reached and reaching it says its own name.
  * An answer nobody declared is DROPPED, which is what keeps the store bounded by the
    client's deferral depth instead of by the server's answer rate. Retain-on-arrival
    grows ~11.3 entries per create against a server that ignores the no-reply bit.
  * A read that fails after WaitForApplied has returned Reached is now Fatal{ReplyMissing}
    naming the seq: on the stream arm the reply frame strictly precedes the progress
    frame that publishes appliedSeq, so that combination is a broken invariant, and
    retrying it (what the row used to do) wedges the window for the rest of the
    process while leaving every deferred object latched on a provisional accept.
  * The residency budget is deleted (WireTables.cpp keeps its history), the window
    retirement branch drains once before falling back - it could otherwise strand the
    answers it was holding - and Detach clears the store.

MEASURED ON THE DEVICE, load frame, both ends rebuilt, frame-sent identical per op
(create 4,536, records 103,097) throughout:

    window 1 (R-5's shape)              4,536 takes   28.66 s
    window 2 explicit                   2,500         17.27 s
    window 2 AS THE SHIPPED DEFAULT     2,563         16.52 s
    window 4                            1,644         11.02 s
    window 2 against an OLD SERVER      2,663         16.38 s   (zero Fatals)

The last row is the version-skew case the design review named as a must: a server
built before the no-reply bit answers ~55,903 records a frame, the whitelist drops
every answer nobody declared, and the deferral still reads its own back.

GATES (172 + 15 green), and the important one is proved to go red:
  * ADeclaredAnswerSurvivesFarMoreInterveningAnswersThanAnyFixedBuffer - reverting the
    store to "keep the last 8 arrivals" fails it immediately with "the declared answer
    did not survive 64 intervening ones". That is the line between the ring-1024
    stand-in and a bounded mechanism.
  * AnAnswerNobodyDeclaredIsNotKeptAtAll - red if everything is retained.
  * TheWindowRefusesToDeferOnALinkThatCannotRetainAnswers - on the in-process (ShmLink)
    arm the knob at 4 must still block every create, red if the capability gate goes.
  * The refused-create case now reads the repair that exists on THAT arm (the latch),
    and asserts the window's own books are empty there.

NOT DONE, and named: the window has no unit gate on the STREAM arm yet - only the
device runs. Three rounds of this feature were green in the lanes while inert on the
device because the lanes and the device run different transports; the transport-level
retention gates close that for the store, and the window-level one should be built on
StreamClientPublicationTest's real stream session next.
2026-09-26 03:31:14 +08:00

MobileGL

C++ GNU LGPL 3.0 Development

A desktop OpenGL implementation

MobileGL is a free and open-source project that implements a desktop OpenGL API. The goal is to provide a complete desktop OpenGL implementation with a state management layer and multi-backend support.

Note

Status: In development. Parts of the codebase are incomplete. Current short-term target: OpenGL 4.2 (Core Profile).

Project positioning

MobileGL is an implementation of a desktop OpenGL library. It aims to provide:

  • Full OpenGL state management.
  • A front-end that exposes OpenGL functions.
  • Multiple independent backend implementations, where each backend targets a specific graphics API and remains fully isolated from others.

This project is intended as an implementation/translation layer.

Key components

The repository is organized into following top-level modules:

  1. MG_State — state tracking and management logic for Graphics APIs.
  2. MG_Impl — front-end implementations of Graphics APIs that interact with MG_State and MG_Backend.
  3. MG_Backend — per-backend translation layer that maps front-end Graphics APIs' semantics and state into concrete backend API calls (e.g. OpenGL ES, Vulkan).
  4. MG_Util and other utility modules.

Third-party components

MobileGL reuses several open-source projects:

Refer to each component's repository for exact license texts. Any bundled third-party code in this repository is included under the upstream project's license.

Compatibility & target

  • Short-term target: OpenGL 4.2 (Core Profile).
  • Current development focus:
    • Performance improvement
    • MG_State and MG_Impl for OpenGL 4.2 (Core Profile)
    • Direct (Vulkan) backend
    • Direct (OpenGL ES) backend

Build Instructions

We currently provide no releases and no precompiled binaries.
If you want to try the project right now, you’ll need to build it yourself:

  1. Clone the repository:

    git clone https://github.com/MobileGL-Dev/MobileGL.git
    
  2. Initialize and update all submodules recursively:

    git submodule update --init --recursive
    
  3. Follow glslang’s own documentation for its required initiation.

  4. Configure and build the project with CMake:

    cmake -B build
    cmake --build build
    

    or do it in a modern way:

    cmake -S . -B build -G Ninja -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++
    cmake --build build
    

    Alternatively, you can use platform-specific build commands as needed.

Build For macOS

On macOS, MobileGL can be built as a dylib that exposes the normal OpenGL/CGL/NSOpenGL entry points and routes them to the DirectVulkan backend. This is useful for running applications such as Minecraft through their stock GLFW/LWJGL OpenGL path while MobileGL is injected before context creation.

Prerequisites:

  • macOS with Clang and Ninja.
  • Vulkan loader and MoltenVK installed. With Homebrew, the MoltenVK ICD is commonly located at /opt/homebrew/etc/vulkan/icd.d/MoltenVK_icd.json.

Configure and build:

cmake -S . -B build-macos-magma \
  -G Ninja \
  -DCMAKE_BUILD_TYPE=Release \
  -DMOBILEGL_BACKEND_TYPE=DirectVulkan \
  -DMOBILEGL_BUILD_TEST=OFF \
  -DMOBILEGL_BUILD_BENCHMARK=OFF

cmake --build build-macos-magma --target MobileGL -j8

The dylib will be generated at:

build-macos-magma/libMobileGL.dylib

To run Minecraft by MobileGL from a launcher like PrismLauncher, keep the stock LWJGL/GLFW natives and add a wrapper command to the instance settings:

env DYLD_INSERT_LIBRARIES=/absolute/path/to/MobileGL/build-macos-magma/libMobileGL.dylib MOBILEGL_BACKEND_TYPE=DirectVulkan VK_ICD_FILENAMES=/opt/homebrew/etc/vulkan/icd.d/MoltenVK_icd.json

Also make sure the JVM arguments include:

-XstartOnFirstThread

DYLD_INSERT_LIBRARIES must be active before GLFW creates its OpenGL context. After startup, the Minecraft F3 screen should report MobileGL and the Direct (Vulkan) backend if the injection worked.

Build Options

Option Description Default
MOBILEGL_BUILD_TEST Build MobileGL tests (requires Clang) ON
MOBILEGL_BUILD_BENCHMARK Build MobileGL benchmarks (requires Clang) ON
MOBILEGL_FORCE_RELEASE_OPT Enable O3 and LTO in Debug build ON
MOBILEGL_ENABLE_TRACY Enable Tracy profiler for performance analysis OFF

Notes:

  • The project requires C++23.
  • MG_Test and MG_Benchmark can only be built with Clang, not GCC. To enforce Clang, add -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ to your command.
  • On Android, tests and benchmarks are always disabled.

Environment Variables

MobileGL supports runtime configuration via environment variables.

Supported Keys

Variable Description Allowed Values Default
MOBILEGL_BACKEND_TYPE Select active backend implementation at startup. DirectGLES, DirectVulkan DirectGLES
MOBILEGL_DISABLE_TIMERQUERY Disable GPU timer-query exposure and use. 0, 1 0
MOBILEGL_ESPRYT_USE_ANGLE Load ANGLE EGL/GLES libraries. 0, 1 0
MOBILEGL_MAGMA_DISABLE_SUBGROUP Disable Vulkan shader subgroup support. 0, 1 0
MOBILEGL_ADVERTISE_FP64 Advertise GL_ARB_gpu_shader_fp64. GLSL double/dvec/dmat compile and run either way - they are narrowed to 32 bits - so this only changes whether an application is told it has 64-bit precision, which it does not. 0, 1 0
MOBILEGL_MAGMA_R11G11B10F_FALLBACK Use Magma's R11G11B10F format fallback. 0, 1 0
MOBILEGL_MAGMA_FRAMESINFLIGHT Set Magma frames in flight. Integer 1–64 3
MOBILEGL_ESPRYT_AVOID_SAMPLER_MIPMAP_MIN_FILTER Avoid sampler mipmap minification filters. 0, 1 0
MOBILEGL_COHERENT_AS_FLUSH Treat persistent GL_MAP_FLUSH_EXPLICIT_BIT maps as coherent (app-compat for engines like Flywheel that never flush them). 0, 1 0
MOBILEGL_ESPRYT_FORCE_DS_READBACK_EMULATION Always emulate depth/stencil glReadPixels/glGetTexImage by shader sampling on Espryt, instead of using the driver's own depth/stencil readback where it has one. 0, 1 0
VK_ICD_FILENAMES Select the Vulkan ICD used by the Vulkan loader. Path to an ICD JSON file Loader default

License

This project is distributed under GNU LGPL v3.0. See the LICENSE file in the repository for detailed information.

S
Description
No description provided
Readme
2.6 GiB
Languages
C++ 84.3%
C 6.1%
Python 5.7%
CMake 1.7%
Shell 1.4%
Other 0.5%