Add Vulkan & Mac Support#614
Open
cochcoder wants to merge 12 commits into
Open
Conversation
… GL behavior change)
…mory/semaphores), shaderc bridge
…lity+Iris gating (GL default)
…ture query, discrete-GPU preference, fixed-count indirect fallback (MoltenVK)
…Vulkan backend, VkComputePipeline infra, macOS host-required gate
… seams for GL/VK parity Voxy now follows MC's own graphics API: when MC 26.2 runs on its Vulkan backend, Voxy adopts the game's VkDevice/queue via a Blaze3D-VK adapter mixin and records all LOD rendering into MC's frame command buffer from a Sodium hook (TAIL of drawChunkLayer/OPAQUE). When MC is on OpenGL, Voxy uses its existing MDIC backend unchanged. No user-facing toggle; no GL fallback either way (no GL context exists under MC-on-Vulkan). Shared CPU pipeline (NodeManager, mesh gen, model bakery, render-distance tracker, viewport math, all GLSL sources via #ifdef VOXY_VULKAN guards) is unmodified between backends; backend-specific glue lives behind seams (IDeviceBuffer, AbstractUpload/DownloadStream, IModelStore, IBasicGeometryData, INodeGpuOps, INodeCleaner, IAtlasTextureReader). Pure-VK render core: compositor (depth setup + alpha composite with env fog), terrain renderer (indexed-indirect-count with MoltenVK fixed-count fallback + visibility-tracked budget), HiZ pyramid (subgroup-reduced), hierarchical traversal, SSAO, depth-bound culling, node cleaner, geometry/model stores, frame context (VkEvent frame retirement + deferred destruction), upload/download streams. MoltenVK: drawIndirectCount feature query + fixed-count fallback, mutable-format D32S8 depth-only sampling, macOS natives for lwjgl-lmdb/zstd, keep osx-arm64 RocksDB native. CmpLog: opt-in (-Dvoxy.cmplog=<path>) A/B parity logging for GL/VK comparison; no-op when unset. Drops the phase-1 GL-interop hybrid renderer (VulkanSectionRenderer/Viewport, SharedBuffer/Image/Semaphore, VkComputePipeline) — superseded by the pure-VK host path.
|
I have been using this, and so far:
macos 26, m5 chip |
|
Been running this on an M3 Pro MBP macos 15.7.4 with no noticeable issues beyond the slight glitch on first world load mentioned above, but that disappears in a split second. I'll take this over no mac support any day. There's an open PR in MoltenVK that adds |
Six MoltenVK-specific fixes that resolve the macOS '2D floating blocks' loading glitch and several latent Vulkan correctness issues: 1. VkTerrainRenderer: gate fixedCountBudget on hasAnyReadback so the first frame with geometry issues 0 draws (not 1024+ no-op Metal draws from the zeroed drawCallBuffer). renderOpaque runs BEFORE buildDrawCalls and uses last frame's commands; on MoltenVK each no-op slot becomes a real Metal drawIndexedPrimitives call, causing the glitch. Desktop Vulkan is unaffected (vkCmdDrawIndexedIndirectCount reads count=0). 2. VkTerrainRenderer: init fbOpaqueDraws/fbTranslucentDraws/fbTemporalDraws to 0 instead of MAX caps (reduces no-op count on subsequent frames too). 3. VkImage2D: UNDEFINED-layout images get TOP_OF_PIPE/0 in transition() and transitionBatch() (no prior producer — contents discarded). Fixes MoltenVK strictness on first-use image barriers. 4. VulkanContext: fix subgroup properties query to use vkGetPhysicalDeviceProperties2 (not Features2 — was silently returning all-zeroes on every device). Gate subgroup paths off via ENABLE_SUBGROUP_PATHS=false until validated (hiz_subgroup.comp has a suspect subgroupBarrier with 4/256 active lanes). 5. VkFrameHost: transition DEPTH|STENCIL aspect together (not DEPTH only) since separateDepthStencilLayouts is never enabled. MoltenVK requires both aspects in the barrier. 6. VkTerrainRenderer: prep->cmdgen barrier now includes COMPUTE in dst stages (cmdgen's atomics are RMW reads of prep's zeroes). Without it, cmdgen could see stale per-frame counters on MoltenVK, placing draw commands at wrong offsets. 7. VkTraversal: WAR barrier between download copy and requestBuffer fill (Metal blit encoders don't serialise like desktop transfer queues). Zero impact on desktop Vulkan: hasDrawIndirectCount=true skips the fixed-count path entirely, and the barrier fixes are strict supersets of the original scopes.
…ection-derived caps and zeroed trailing slots - Remove unused fbDraws/fbMax/hasAnyReadback ratchet fields and VkDownloadStream import - Remove fixedCountBudget() wrapper (was identity), inline cap as maxDraw - MoltenVK fallback: zero only cap-sized regions of drawCallBuffer per frame - Include COMPUTE stage in prep->cmdgen barrier for MoltenVK atomic visibility - Compact all comments to single-line annotations
…c with section-derived caps and zeroed trailing slots" This reverts commit 00939a9.
This reverts commit 7e1ccb8.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds a Vulkan render path that runs when MC 26.2 is on its own Vulkan backend. Following whatever MC's API is set to.
When MC is on Vulkan, Voxy adopts the game's
VkDevice/queue via a Blaze3D-VK adapter mixin and records all LOD rendering into MC's frame command buffer from a Sodium hook (TAIL ofdrawChunkLayer/OPAQUE). When MC is on OpenGL, the existing MDIC backend runs unchanged. No GL fallback either way with no GL context existing under MC-on-Vulkan.Architecture:
client/core/vk/render/): compositor, terrain renderer (indexed-indirect-count with MoltenVK fixed-count fallback), HiZ, traversal, SSAO, depth-bound culling, frame context (VkEvent retirement + deferred destruction), streams.IDeviceBuffer,AbstractUpload/DownloadStream,IModelStore,IBasicGeometryData,INodeGpuOps,INodeCleaner,IAtlasTextureReader.#ifdef VOXY_VULKANguards.MoltenVK:
drawIndirectCountfeature query + fixed-count fallback, mutable-format D32S8 depth-only sampling, macOS natives forlwjgl-lmdb/lwjgl-zstd.Verified: builds clean, 25/25 shaders compile, in-game LOD rendering on desktop Vulkan + MoltenVK, verified compatable with mods in Fabulously Optimized.
Performance: With a render distance of 260 chunks, OpenGL performance remains the same while Vulkan provides close to 200 FPS uplift on my Laptop with a RTX 5070 Ti (on CachyOS). While a Macbook Air M4 gives around 200 FPS in a vanilla world with 260 chunks.
- BadOptimizations
- EntityCulling
- FerriteCore
- ImmediatelyFast
- Lithium
- Moonrise
- More Culling
- Sodium
- Sodium Extra
- Voxy World Gen V2
- Zoomify
fixes #208, fixes #607, fixes (mostly) #432