An open-source OpenGL 4.6 Core implementation atop Apple's Metal API, written in Rust
- Easy to develop and hack on
- builds a working artifact with a simple
cargo build
- reasonable initial build times (around a minute on a 2010 6 core xeon)
- focus on safety and correctness before maximum performance (prefer safe code, optimize where needed with unsafe later)
- builds a working artifact with a simple
- Run Minecraft
- Have decent performance
- Automate as much tedium as possible by leveraging OpenGL's machine-readable spec and reference
- Full OpenGL 4.6 compliance (Metal itself is not specified strongly enough for this to be worthwhile)
- Multithreading support/share context (this may actually be practical,
Context
is currently stillSend
)
- xtask system capable of:
- building and OxideGL and its GLFW fork and running other utilities
- code generation of a placeholder GL implementation, as well as Rust enums for the allowed parameters of many functions that take
GLenum
parameters
- Context creation and linkage with GLFW
- Generic context parameter lookup (
glGet
and co.) - full implementation of VAOs (some features disabled due to limitations in shader translation)
- initial implementation of buffers and buffer binding (currently missing buffer copy operations)
- initial implementation of shaders and shader programs
- initial implementation of shader translation using the
glslang
andspirv_cross2
binding crates - initial GL state -> metal state translation in progress
To get a full list of OxideGL xtask
subcommands, run cargo xtask --help
anywhere in this repository.
All tasks implicitly run the necessary dependencies (e.g. cargo xtask build-glfw
implies cargo xtask gen-glfw-build
etc), so you don't need to run dependencies of tasks manually.
This project uses Clippy for linting. If you use VS Code or a derivative thereof, this should be enabled already (via a .vscode
with the appropriate configuration in the repository root). If not, check if your IDE supports changing the rust analyzer check command or simply run cargo clippy
from your shell.
Since this implementation only provides a GL_NOERROR
context, its behavior in an errored state may be undefined according to the GL spec. In release builds, upon recieving erroring input, OxideGL will propagate UB (i.e. raise GL UB to Rust language level UB) where there is a measurable and significant performance advantage in doing so (e.g. skipping array bounds checking in a hot path), otherwise it will abort the calling program. However, in debug builds, OxideGL will attempt to abort with a helpful message (and a stack trace including the calling function that caused the error) as soon as possible after recieving an incorrect input.