[Bill Hollings]

No…this is not a known issue…and has not been reported before.

Do you have a small sample app that you can submit that demonstrates the problem?

Alternately…it has not been made public yet…but MoltenVK is transitioning to an open-source model. If you provide your GitHub user ID via our Contact form (or see the button below), we can provide you with access to the open-source MoltenVK Beta on GitHub. You will then be able to trace what is happening to your vertex attributes in the MoltenVK source code.

[Bill Hollings]

The second issue has been fixed now.

Good news! MoltenVK is transitioning to an open-source model. It has not been made public yet…but if you provide your GitHub user ID via our Contact form (or see the button below), we can provide you with access to the open-source MoltenVK Beta on GitHub.

[Bill Hollings]

@oscarbg

Thanks for reporting this. It turns out that macOS/OSX Metal 2.0 does not support the memory_scope feature…so it is being generated in error on macOS High Sierra.

We will fix this in the next release.

…Bill

[Bill Hollings]

@kerlingb

The appearance of unsupported_GLSLstd450UnpackHalf2x16() indicates that you are trying to use an unpacking function (ie. GLSL unpackHalf2x16()) that is not supported by Metal. Metal does not support the unpacking of one 32-bit integer into two half float values.

The other errors, to do with passing arguments between functions, is a bug in the shader converter. We will review that and fix it.

…Bill

[Bill Hollings]

@Daniel

The header files used by MoltenGL are the standard OpenGL ES header files.

The redirection headers, which you use to redirect OpenGL ES calls to Metal when you link MoltenGL to your application, are included in the MoltenGL distribution in the MoltenGL/RedirectHeaders/include/OpenGLES/ES2 directory.

The original headers are included in the MoltenGL/RedirectHeaders/orig/OpenGLES/ES2 directory.

…Bill

[Bill Hollings]

@golddranks

With v0.19.0, MoltenVK supports using IOSurfaces for VkImages…and requires access to the IOSurface framework during compilation.

You need to link the IOSurface framework into your app. See the Installing MoltenVK in Your Vulkan Application section in the README_MoltenVK_UserGuide.md document in your Molten distribution package for more info. You will need to build using Xcode 9.0 to include this framework for iOS.

You do not need to have this framework available in order to run your application…but you do need it to build your application.

[Bill Hollings]

@mtesseract

Yes…MolenVK is compatible with vulkan.hpp…and that file appears included in the MoltenVK/include/vulkan directory within the Molten distribution.

…Bill

[Bill Hollings]

@golddranks & @robtsuk

Yes…the excessive logging is a MoltenVK issue.

It has been corrected for the next release of MoltenVK.

…Bill

[Bill Hollings]

@nholzschuch

Sorry for the delay in responding.

I’m wondering if it is an issue with the Assimp build.

I’ve updated the Brenwill fork of the SW Vulkan repository to include stable compiled Assimp libraries for macOS and iOS. This also drastically simplifies installation of the examples.

Try re-cloning the https://github.com/brenwill/Vulkan.git repository. The only thing you have to do then is update the Vulkan/xcode/MoltenVK symlink (or put your Molten distribution in the same directory as the cloned Brenwill SWVulkan repository.

Let me know if that fixes things.

…Bill

[Bill Hollings]

@kruseborn

Unfortunately, I am not able to replicate this issue here.

Can you confirm behaviour with the MoltenVK demos, as follows, please?

In the Hologram.cpp file within the MoltenVK Demos…after the line (557):

vk::assert_success(vk::AllocateDescriptorSets(dev_, &set_info, desc_sets.data()));

add the following two lines:

vk::assert_success(vk::FreeDescriptorSets(dev_, desc_pool_, set_info.descriptorSetCount, desc_sets.data()));
vk::assert_success(vk::AllocateDescriptorSets(dev_, &set_info, desc_sets.data()));

Effectively…this is allocating the descriptor sets, then freeing them, then allocating them again. It works as expected.

Removing the FreeDescriptorSets line causes the error that you are seeing to be returned…again as expected.

Let me know if that helps you resolve your issue, or whether the it persists for some reason.

…Bill

[Bill Hollings]

@mtesseract

Unfortunately, LunarG’s validation layers have not been ported to macOS and iOS yet. We have had some discussions with LunarG about this…but it has not yet become a priority for either company.

You can help by posting the same request to LunarG…to help raise this as a priority.

Regarding using CMake, sorry…we have not built MoltenVK using CMake yet…so I can’t comment on whether your approach is optimal.

…Bill

[Bill Hollings]

@Nholzschuch

Sorry that you’re having trouble.

Strange. Does this happen with all of the S-W examples? (the doc you mentioned and the examples.h file explain how to select the example to run).

…Bill

[Bill Hollings]

@kruseborn

Thanks for reporting back your results. I’m glad it worked for you.

Based on your feedback…for the next MoltenVK release…I’ve added VK_AMD_negative_viewport_height to the list of supported extensions reported by the MoltenVK driver…and in the MoltenVK documentation.

…Bill

[Bill Hollings]

@kruseborn

MoltenVK does not currently directly support either of those extensions.

However, the Vulkan VkViewport information is passed directly to the Metal MTLViewport…which does allow flipping.

Have you tried it? Does providing a negative height in VkViewport to MoltenVK perform the flipping that you expect?

…Bill

[Bill Hollings]

@tracyma

Unfortunately…the direct use of pre-existing MTLTextures is not available in the MoltenVK API.

I’ve put it on the list of development activities for a future release though.

…Bill

[Bill Hollings]

@marie

Hmmm…are you building on Sierra or El Capitan?

MTLFunctionConstantValues was introduced in macOS 10.12 (Sierra).

MoltenVK will run on macOS 10.11…but it is built…and expects to be linked…in macOS 10.12.

…Bill

[Bill Hollings]

@tracyma

When copying from a buffer to an image using vkCmdCopyBufferToImage(), both Vulkan and Metal require that the bufferOffset value be a multiple of the image element size…which in the case of compressed formats is its block size.

For example…the block sizes for VK_FORMAT_ETC2_R8G8B8_UNORM_BLOCK and VK_FORMAT_ASTC_6x6_UNORM_BLOCK are 8 and 16, respectively…which is why you are seeing those two errors.

From looking at your code sample…given that Metal is complaining about a 4 byte offset…my guess is that your call is expecting that the first 4 bytes of each Mip layer contains the size of the layer…and your function skips those first 4 bytes by incrementing bufferOffset by those 4 bytes. That will then cause bufferOffset to have a value of 4…which is not a multiple of either of the compressed format block sizes you are using.

…Bill

[Bill Hollings]

@marie

Sorry for the delay in responding.

Thanks for letting us know about this.

There was a configuration error in the submodule configuration for the brenwill/Cinder repository…which has been fixed now.

Please follow the instructions again…including the recursive clone of the brenwill/Cinder repository. It should work now.

Thanks…

…Bill

[Bill Hollings]

Thanks for bringing this to our attention.

We’ll look into it.

…Bill

[Bill Hollings]

@oscarbg

I’ve posted a question about geometry shaders to that VMware forum. I’ll be curious about how they are implemented.

There should be no limitation on screen resolution under macOS. Can you identify a case where you are seeing such a limitation?

…Bill

[Bill Hollings]

@oscarbg

Thanks for raising this.

Where are you reading that geo shaders are supported? The only reference I could find doesn’t seem to indicate that…or at least indicates that if they exist…they have been implemented in some form of middle layer.

If that is the case…I’m not sure we would get into trying to emulate geometry shaders. Geometry shaders are optional under Vulkan.

…Bill

[Bill Hollings]

@oscarbg

Pointers and 16-bit int and float in/out variables should be acceptable in Metal.

And yes…we plan to support this as much as possible in MoltenVK.

…Bill

[Bill Hollings]

@chenditc

The glString() function under MoltenGL operates as expected once the EAGLContext has been established.

Your code…

const GLenum gl_VENDOR = 0x1F00;
const GLubyte* stringPointer0 = glGetString(gl_VENDOR + 0);
const GLubyte* stringPointer1 = glGetString(gl_VENDOR + 1);
const GLubyte* stringPointer2 = glGetString(gl_VENDOR + 2);

printf("Vendor + 0: %s\n", stringPointer0);
printf("Vendor + 1: %s\n", stringPointer1);
printf("Vendor + 2: %s\n", stringPointer2);

produces the following output…

Vendor + 0: The Brenwill Workshop Ltd.
Vendor + 1: MoltenGL
Vendor + 2: OpenGL ES 2.0 MoltenGL 0.18.1 (build 0)

However…if the EAGLContext has not been established yet…the missing context will cause all GLES function calls to crash.

In your plugin…is it possible for you to ensure the EAGLContext is established before the glString() calls are made?

EAGLContext* ctx = [[EAGLContext alloc] initWithAPI: kEAGLRenderingAPIOpenGLES2];
[EAGLContext setCurrentContext: ctx];

…Bill

[Bill Hollings]

@chenditc

I’m afraid that we do not directly support MoltenGL integrated to a Unity plug-in.

Be sure to review the installation instructions in the README_MoltenGL_UserGuide.md document.

It is important that all OpenGL ES calls made by your plugin (and Unity) are redirected through the MoltenGL headers. It is also important that the UIView that is used is backed by a CAMetalLayer.

…Bill

[Bill Hollings]

@skalarproduktraum

Support for gl_FragDepth is now available.

Thanks for your suggestion about breaking a sampler array into individual components. We’ll look into that for backward compatibility when we implement the feature. There might be issues with shader conversion from SPIR-V though.

…Bill

[Author]

Posts