Really curious about LunarG
Having spent ~1hr getting acquainted with the MoltenVK SDK, I have to say that it’s quite straightforward to use, if verbose (because Vk). Here’s a cheeky little cube (3.2kLOC):pic.twitter.com/oCVYJmaqfv
-
-
-
What specifically? As I understand it, they’re a Colorado company that’s closely partnered with Khronos to develop software for the Vulkan ecosystem (https://www.lunarg.com/about/ ).
-
Yeah more about the integration between MoltenVK and the LunarG SDK. MoltenVK seems to use LunarG, is that where the core Vulkan SDK is coming from or is it just for additional tooling?
-
I’ll be honest: I don’t know the exact relationships/partnerships among Brenwill, LunarG, Valve, and Khronos that brought this about.
-
Valve is one of many Khronos members who contribute to the (ongoing) Vulkan specification. We support FOSS SDKs and tools to make Vulkan a more complete ecosystem. We strive to put our own game workloads on drivers and use the tools & SDKs to help improve them.
-
Everybody involved thought integrating MoltenVK into LunarG so SDKs and tools worked seamlessly, have a loader, eventually support layers, (and MoltenVK could run all SDK samples) would make developers' lives easier. Hope it was an OK call :)
-
I think it’s terrific! It’s been fun getting acquainted with Vulkan via MoltenVK, even though I’m likely to remain Metal-centric for the foreseeable
-
Using Metal is A-OK and great :) - our SteamVR compositor is native Metal to maximize VR performance. What I like about MoltenVK is it's so thin you can easily reach through to Metal as needed. More graphics programmers on macOS and iOS will always be a good thing.
- 2 more replies
New conversation -
-
-
3.2kLOC?!! Wtf! Even allowing for a lot of “pointless, but doing it by the book” code, thats… a lot past a lot. Comparison: My entire Metal-based IDE with UI, multipass rendering and such is 2,755 LOC.
-
It’s just this with all of the platform-specific stuff stripped: https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/blob/master/demos/cube.c … I think it could be tersified down to, perhaps, 700 LOC, but not much less.
-
Would be interesting to see how far it can be squeezed. Be surprised if it can’t be done in ~20 lines in metal. Doesn’t give me much faith in VK, its giving so much extra scope for bugs and performance issues to creep in :(
-
It’s ~75 lines in Metal if you lean on MetalKit and Model I/O. That’s without golfing down to the bare minimum.
-
10:1. To me, a good API is clear and concise. Vulkan is failing very hard at concise :( Which tends to have a negative effect on clear too. Then again, it shows how nice Metal is!
-
Turns out 700 was overly optimistic. I was able to whittle it down to about 1500 sloc: https://github.com/warrenm/HelloVulkanMac/blob/master/HelloVulkanMac/Renderer.m …
-
Oof. I can see there being some benefits, but imagine your productivity levels, trying to code something non-trivial like that!
End of conversation
New conversation -
-
-
3.2k loc? How much is that compared to a pure native Vulkan equivalent?
-
The same, give or take some windowing code.
End of conversation
New conversation -
-
-
i love cubes.
-
Next up: a chrome sphere on a checkerboard.
End of conversation
New conversation -
-
-
thanks for taking it for a whirl - feedback appreciated :)
-
One small nit: why require a view instance on Vk*OSSurfaceCreateInfoMVK? It seems like a CAMetalLayer would do just as well.
-
a valid point - intended to match the view/window mapping of other platforms' Vk*SurfaceCreateInfoKHR. it might make sense to support either a CAMetalLayer-backed view or just a CAMetalLayer.
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.