Graphics Engineer · Vulkan / OpenGL

About Dawn / InPvP

InPvP is one of the biggest companies in the Minecraft space, with four featured Bedrock servers, plus 2 more coming later this year, as well as other major unannounced projects and acquisitions coming by EoY. We deliver high quality experiences and value our partnership with Microsoft/Mojang.

We took over the Feather Client to do right by its community. Dawn, formerly Feather Client, is InPvP's cross-platform launcher + client built for PvP performance and strong modding features. It is the fastest growing Minecraft client in the space and is currently undergoing major rewrites and bug fixing from tech debt accumulated over the past year. We need a perfect product before we start marketing, so it's all hands on deck.

Background

Dawn has 26 Minecraft versions, from 1.8.9 to the latest snapshots, on both Fabric and Forge, with a large active player base. Inside it there's a render graph running over a custom RHI. It was designed to support:

• ·OpenGL 2.0 (Legacy Minecraft on macOS, no way to extend it via OpenGL 3.0 core)
• ·OpenGL 3.3 (old hardware)
• ·OpenGL 4.1 (latest macOS supports)
• ·OpenGL 4.3 (Compute shaders gate)
• ·OpenGL 4.5 (DSA gate)
• ·OpenGL 4.6
• ·Vulkan

What you'd work on

Both backends, OpenGL and Vulkan, are already implemented and rendering the game today. The work isn't to bring Vulkan to life; it's already there. The execution model is fairly new, so part of the work is bringing it down to older Minecraft versions that predate it, back to 1.17.1, across the point where Minecraft moved to core shaders. System should support both Forward-Z and Reverse-Z and switch at runtime.

• ·The RHI abstraction: the contract, synchronization and barriers, pipelines and descriptors, SPIR-V, and getting both backends to sit cleanly behind it.
• ·Render-graph passes, draw-call batching and geometry merging, and shader paths.
• ·GPU profiling and optimization with RenderDoc, Nsight, and Tracy, and learning the JVM side too, because on a managed runtime the CPU/GPU boundary matters more than you'd expect.
• ·Validation errors, vendor-specific driver bugs, and rendering differences across versions.
• ·Our own rendering pipelines, like an independent text stack with its own shader and glyph atlas, built so shader mods and font mods can't corrupt it.

Experience we're looking for

• ·Real graphics experience in Vulkan and/or OpenGL: render state, buffers, pipelines, synchronization, and debugging them when they misbehave.
• ·A C++ systems background. Ideally you picked it up before AI tools were doing the reasoning for you, so you can think about memory, lifetimes, and performance yourself.
• ·If you've built your own renderer or engine, that's the single strongest thing you can show us for this track.
• ·Linear algebra and graphics math: matrices, transforms, projections.
• ·You don't need Java. You do need to be willing to learn it and work inside a large JVM codebase.

A big plus: performance Java

Java is not required for this track, but if you also happen to be a performance-minded JVM engineer, that combination is rare and we want it badly. We render on a managed runtime, so the CPU side of the frame lives or dies on JVM behavior.

By performance-minded we mean someone who reads JIT compilation logs and knows how C2 inlines, when it bails to a megamorphic call site, and what on-stack replacement and deopt are doing to a hot loop; who watches escape analysis and scalar replacement decide whether an object ever reaches the heap; who tracks allocation rate against GC pauses (G1, ZGC, Shenandoah) and reaches for async-profiler or JFR before guessing. If that's you on top of the graphics background, you're exactly the unicorn we're hoping to find.

Nice to have

• ·GLSL or SPIR-V shader work, and time spent around shader mods (Iris, OptiFine, Sodium).
• ·Comfort reverse-engineering undocumented behavior, whether it's a driver, a runtime, or the game.
• ·Some curiosity about the JVM: how the JIT, GC, and memory model shape performance.
• ·Minecraft modding (Mixins, mappings). A head start, not a requirement.
• ·Gradle and multi-target builds, JNI.

What's hard about it

None of this is easy and I want to personally say this upfront: if you can't keep up with pressure and a fast-moving environment you will get cut. InPvP, across all of its projects, moves fast, ships fast, and has no tolerance for slacking.

Logistics

• ·Fully remote
• ·Independent contractor
• ·Minimum 40 hrs/week
• ·Pay is competitive and not tied to your location, with a performance review and a raise every six months. InPvP pays the highest rates in the space, across all positions for all of our projects.

Applying

Email [email protected] with a CV and send something interesting like a mod you shipped, a performance project, a pull request or writeup where you chased a hard bug all the way down. Tell us the worst performance or correctness problem you've fixed, and how you knew it was actually fixed.