Files

94 lines
4.2 KiB
Markdown

# MobileGL on Windows (WGL `opengl32.dll` drop-in)
On Windows, MobileGL builds as `MobileGL.dll` plus an identical copy named `opengl32.dll`. The copy
exports the WGL entry points (`wglCreateContext`, `wglGetProcAddress`, `wglSwapBuffers`, ...) and
the OpenGL functions. A program that loads `opengl32.dll` from its own directory gets MobileGL
instead of the system OpenGL driver.
## When to use it
- You want to run a Windows OpenGL program (for example Minecraft through GLFW/LWJGL) on MobileGL,
to test MobileGL or to compare its backends on desktop hardware.
When not to use it:
- Split rendering. On Windows only monolith is supported; the server executable is not built for
Windows.
- As a system-wide driver. Do not replace `C:\Windows\System32\opengl32.dll`. The drop-in works per
application directory.
> **Build status on the current branch:** building `feat/disaggregated` with MSVC 19.38
> (Visual Studio 2022 17.8) fails with `error C2610` in `MobileGL/MG_Util/Damage/Damage.h` (a
> defaulted `operator==`) and the same error in several Magma headers. Newer MSVC toolsets were not
> tested. The steps below are the ones the Windows tooling in this repository uses
> (`tools/cts/scripts/wgl_glcts_pipeline.py`); they apply once the tree builds with your compiler.
## Requirements
- Windows x64, Visual Studio 2022 with the Desktop C++ workload, CMake, Python 3, Git.
- The Vulkan SDK, so that CMake's `find_package(Vulkan)` finds it.
- For **Magma**: a Vulkan driver for your GPU (`vulkan-1.dll` and a vendor ICD). The SDK alone
provides no GPU device.
- For **Espryt**: Espryt on Windows always runs on ANGLE. Put matching x64 `libEGL.dll`,
`libGLESv2.dll` and `d3dcompiler_47.dll` from one ANGLE build next to the program.
## Build
Prepare the sources first (submodules and glslang's external sources, see
[building.md](building.md#get-the-sources)). Then, from the repository root:
```powershell
cmake -S . -B C:\mgl-build -G "Visual Studio 17 2022" -A x64 -DMOBILEGL_BUILD_TEST=OFF -DMOBILEGL_BUILD_BENCHMARK=OFF
```
```powershell
cmake --build C:\mgl-build --config Release --target MobileGL
```
Keep the build directory path short: a full build under a deep path can exceed Windows' path length
limit. The result is `C:\mgl-build\Release\MobileGL.dll` and `C:\mgl-build\Release\opengl32.dll`
(with the Ninja generator, both are directly in the build directory).
## Install
Copy `opengl32.dll` into the directory of the executable that creates the GL context. Windows
searches the application's directory before `System32`, so the copy wins.
| Program | Where `opengl32.dll` goes |
|---|---|
| A native `.exe` | next to the `.exe` |
| A Java program (Minecraft) | next to the `java.exe` / `javaw.exe` that runs it, in the runtime's `bin` directory. Use a private copy of the Java runtime so other programs are not affected. |
For Espryt, put the three ANGLE DLLs in the same directory.
## Configure and run
Settings are environment variables ([configuration.md](configuration.md)). Set them in the shell
that starts the program, or in your launcher's environment settings:
```powershell
$env:MOBILEGL_BACKEND_TYPE = "DirectVulkan"
```
```powershell
$env:MOBILEGL_LOG_FILE_PATH = "$PWD\mobilegl.log"
```
MobileGL does not log to the console on Windows, and writes no log file unless
`MOBILEGL_LOG_FILE_PATH` is set.
## How to tell it works
- The program reports `GL_RENDERER` = `Magma (MobileGL Core) (...)` or `Espryt (MobileGL Core) (...)`.
In Minecraft, look at the F3 screen.
- The log file exists and contains `Config: Active backend type set to DirectVulkan`.
- For Espryt, the log has `Loaded GL backend library: libGLESv2.dll` / `libEGL.dll`.
- `tools/wgl-smoke/` has two small test programs (a hand-written WGL bootstrap and a GLFW one) that
render a triangle and check it with `glReadPixels`. Exit code 0 means pass. Build instructions are
in `tools/wgl-smoke/README.md`.
- `tools/cts/scripts/wgl_glcts_pipeline.py` runs the Khronos OpenGL conformance suites against the
drop-in. Its preflight checks that the suite really loaded MobileGL.
If the program still reports your GPU vendor's renderer, it loaded the system `opengl32.dll`:
check that the copy sits next to the executable that actually creates the context.