WIP: VK_EXT_mesh_shader #1845
WIP: VK_EXT_mesh_shader #1845
Conversation
Thanks for the effort! If this will be under dev for a bit, would it help if I created a |
|
@billhollings Yes, that would be a nice idea! |
I've created a |
|
|
|
Quick update: The mesh shaders are working now, we tested with our mesh shader example: The next step would be to test if task shaders are working too: |
|
Any update on this PR? This is amazing |
|
@alexsch01 There are still a few things that need to be done to get the PR ready. For example, the properties and features structures still need to be filled, and it hasn't been extensively tested yet, for example the task shader implementation hasn't been tested apart from a simple dummy task shader. Also, we are still waiting for the pull request that implements MSL mesh shaders in Spirv-Cross to be merged. There are still problems here, as HLSL mesh shaders for example do not yet work at all with the Spirv-Cross version. In the meantime, if anyone wants to test their own mesh and task shaders, they are welcome to do so and feedback is always appreciated. |
|
I have updated the branch. Could you reset the mesh-shader branch to the current main state? Then there would be no more merge conflicts and we could merge the part into the mesh_shader branch 🙂 @billhollings Also, it's interesting that the Apple M3 now has hardware support for mesh shaders. I have no device at the moment, but @zmarlon may have in a few weeks, which would be really interesting to test how mesh shaders on apple hardware actually perform. |
|
Hope it's not rude to tag u another time @billhollings . If you haven't missed it by accident, just ignore it :) |
No worries. I do sometimes need reminding. 😉
You should be able to do this yourself. That way you can fix any conflicts in a way that is compatible with your branch work, rather than have me try to arbitrate any conflicts. Is there a reason why you need me to do it? |
My plan was just to rebase KhronosGroup:mesh-shader to main and then merge my PR into the main, but I have no access to do so |
|
Sorry...that was my bad. I was confusing the PR with the branch. The |
Not worth the performance hit to everything else
Don't enable PixelFormatView just in case we need it to copy
- Add MoltenVK_Configuration_Parameters.md to document the MoltenVK configuration parameters. - Deprecate vkSetMoltenVKConfigurationMVK(). - Deprecate mvk_config.h and move content to mvk_private_api.h and mvk_deprecated_api.h. - Streamline lock on retrieval of MVKLayerManager singleton (unrelated).
…-unified memory devices
Fix heapUsage query for non-unified memory devices
…havior. - MVKGraphicsPipeline::isRenderingPoints() fix regression error to support dynamically setting point topology. - Move emulation of VK_POLYGON_MODE_POINT in Metal, if the polygon model is static, to MVKRenderingCommandEncoderState, to handle dynamic setting of topology. - MVKDevice populate VkPhysicalDeviceExtendedDynamicState3PropertiesEXT. - Move error reporting in mvkMTLTriangleFillModeFromVkPolygonModeInObj() to encoding. - MVKRenderingCommandEncoderState::setCullMode() use getContent() for readability and consistency (unrelated). - Pass pipeline object to datatype functions for reporting accuracy (unrelated).
use sysctlbyname("hw.memsize") to get sytem memory size instead of host_info,
host_info is not available on tvOS, so we change to sysctlbyname which support all apple platforms
apple document didn't stat this API is available on tvOS though,
https://developer.apple.com/documentation/kernel/1387446-sysctlbyname
…topology Fix regression error and properties in point-topology/polygon-mode behavior.
…-size Fix system memory size of tvOS
…sion. - Document the name of the MoltenVK driver layer. - Support future multiple string members in MVKConfiguration. - Add static assert on number of string members in MVKConfigruation. - Rename global mvkConfig() to getGlobalMVKConfig(). - Rename global mvkSetConfig() to mvkSetGlobalConfig(). - Remove unused mvkPrintSizeOf() macro. (unrelated). - Trim trailing spaces from Markdown documents because it causes double-spaces in some Markdown readers (unrelated).
Document GPU capture.
- Remove support for deprecated -[MTLRenderCommandEncoder textureBarrier] and deprecate MVKPhysicalDeviceMetalFeatures::textureBarriers. - Update minimum macOS deployment target to 10.15. - Update minimum iOS/tvOS deployment target to 13.0. - Update Whats_New.md document.
….280 Update dependency libraries to match Vulkan SDK 1.3.280.
Update MoltenVK version to 1.2.9.
…orrect-project-version Fix compilation issue due to new project version
- .gitignore exclude all directories under External, to allow temp directories to be created during dependency developments. - .gitignore specify MoltenVK exclusions are relative to root directory.
Update .gitignore.
…sentSwapchains perf counters
…ents of execute() function
Add "previous" member to MVKPerformanceTracker structure
- Create symlink from MoltenVK/dylib to MoltenVK/dynamic/dylib.
…directory To support legacy apps, restore MoltenVK/dylib directory.
…ndencies. After the recent change to building dynamic frameworks and dylibs as targets built by linking to a static library dependency, incremental builds do not correctly link the dynamic frameworks and dylibs to the rebuilt static library. - Delete dynamic target outputs during static target builds. - Run platform schemes sequentially in manual order. - Build the dynamic framework before the dylib. - Clean up Xcode Scheme organization. It is not entirely obvious what the dependency problem is, and why these particular changes work. A lot of trial-and-error was required. It's possible that Xcode dependency analysis does not correctly analyze the flow used in MoltenVK builds.
Fix issue where incremental dynamic builds do not link to static dependencies.
doc moltenvk link CoreGraphics and AppKit framework
Apple's Automatic Reference Counting automatically releases the Metal objects returned by VK_EXT_metal_objects. The fetchDependencies script now applies Templates/Vulkan-Headers/VK_EXT_metal_objects-unret.gitdiff to add an __unsafe_unretained ownership qualifier to the Metal object declarations in vulkan_metal.h. This should be a temporary patch until the VK_EXT_metal_objects extension can be properly modified.
…bjects-ARC Fix crash when using VK_EXT_metal_objects under ARC.
|
@billhollings can you change the head branch from |
I'm not sure I understand what you are asking? Do you mean you have moved your forked and modified code from If so, I can't find any way to do that. Let me know if you know of a way to do that. BTW...it would be much better to update the 123 commits into the If you don't have permissions to do that, I can take care of it. |
yep, thats what I mean. Unfortunately I cannot change it too, thats why I though maybe you have the permission to do. But if you cannot do it, it looks like github does not have the feature and I have to make a new pull request.
yea good point, I have no permission so it would be nice if you do this :) |
Done. |
I'm adding mesh shader support to MoltenVK together with @zmarlon based on https://github.com/Try/Spirv-Cross/tree/msl-mesh-shader .
At the moment, it is not very functional at all, only a basic triangle is rendering.