-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MoltenVK
failing to resolve GetDeviceXxxMemoryRequirements
#105
Comments
I googled a bit and I have found that MoltenVK does support |
For example: |
I tried a couple more things, i separated out the windowing logic so i don't get this double linking problem im seeing. the rendering code is loaded from another library but i don't see why this would be problem. this looks similar to what is happening but, im a little flumixed why this is not working.
|
I'm happy to help, but I don't know how. |
Yeah, I can try to run it on my Macbook Air M1. Most likely it's an SDK version issue. |
@dzhdanNV I got a response from moltenvk looks like maintenance 4 ext is not available KhronosGroup/MoltenVK#2394 |
Thanks for digging. I would say it's unexpectedly expected. Of course, I take the responsibility for migrating from Solutions:
Other suggestions? |
i might just work on the metal branch more might take a while before i get it to a working state. |
MoltenVK
failing to resolve GetDeviceXxxMemoryRequirements
Please, let me know if you want to get back |
here is the ticket to track for getting samples to work again: |
NRI has become fully VK v1.3 conformant. Moreover, VK v1.4 is around the corner. But MoltenVK does still barely support VK v1.2. Hope the community will push to the success or we get a native Metal implementation instead. |
Hi! I stumbled here after my OSX app reported this during VK extension enumeration:
If I understand correctly, NRI makes use of VK_KHR_maintenance4 which is currently not supported yet in MoltenVK. I recall using NRI sometime last year with MoltenVK without issue, so it seems the hard dependency on VK_KHR_maintenance4 recently added when NRI became VK 1.3 conformant? If so, it seems like your "option 2":
May be the path of least resistance for NRI to work on OSX again, at least until they finish catching up MoltenVK to 1.3 :) Edit: I wound up just merging that stale maintenance4 MoltenVK branch with latest on main and deployed the new binaries to /usr/. NRI device creation now succeeds. I know I am asking for trouble by using an unfinished PR, but at least this let me proceed with development in the meantime. |
Do you mind to look through README (which now includes the list of required VK extensions) and post here unsupported, please? Or is it only
Actually it's unrelated. I switched to Statements:
|
@pollend @parsaiej @vertver, would it be enough to do this:
Thoughts? |
These extensions stays required:
Is it a problem for MoltenVK? |
Yes, it's no problem for MoltenVK - KhronosGroup/MoltenVK#1930. The only extension that is currently not supported is VK_KHR_maintenance4, so that should be fine. Other than that, I don't think the other changes are that critical (it's nice to have GetMemoryDesc without a handle, but I don't use it often). |
I always weep when I do a breaking change, but it's for the better future. Hope these breaking changes are acceptable for users. The good news is that I don't see a reason why old-school "non-2" should be removed. These functions are handy in situations when you already have an object. It happens very often. It happens even more often in some use cases. |
I already implemented this. I will commit tomorrow alongside with modified NRI samples (will switch most of them to non-2, add |
The problem has been solved in the latest release (v1.160). Now Core API has this: void (NRI_CALL *GetBufferMemoryDesc)(const NriRef(Buffer) buffer, Nri(MemoryLocation) memoryLocation, NriOut NriRef(MemoryDesc) memoryDesc);
void (NRI_CALL *GetTextureMemoryDesc)(const NriRef(Texture) texture, Nri(MemoryLocation) memoryLocation, NriOut NriRef(MemoryDesc) memoryDesc);
void (NRI_CALL *GetBufferMemoryDesc2)(const NriRef(Device) device, const NriRef(BufferDesc) bufferDesc, Nri(MemoryLocation) memoryLocation, NriOut NriRef(MemoryDesc) memoryDesc); // requires "isGetMemoryDesc2Supported"
void (NRI_CALL *GetTextureMemoryDesc2)(const NriRef(Device) device, const NriRef(TextureDesc) textureDesc, Nri(MemoryLocation) memoryLocation, NriOut NriRef(MemoryDesc) memoryDesc); // requires "isGetMemoryDesc2Supported"
struct DeviceDesc {
...
uint32_t isGetMemoryDesc2Supported : 1; // D3D: always supported, VK: requires "maintenance4" support
...
}; Same logic has been applied to The last step - could someone try it on an APPLE device, please? (NRI itself or samples) |
I only have time to test this in my own app at the moment (there seem to be some build issues with NRISamples for OSX), but device creation at least works like a charm now. Many thanks for this! I can submit a PR to fix some of the build/compile issues I see for the samples on OSX, its a little tedious though since there are several issues through the submodules, so would need to do one for each submodule. |
Thanks for testing! Hope someone fixes NRI samples on OSX (again, doh) :) |
for the moment i was trying to use MoltenVK for my project. I'm unable to resolve these methods below I wonder if moltenVK provides these interfaces? just wanted to see if it would be possible to just use this but if worse comes to worse its more ideal to just support metal directly then using an intermediary api.
The text was updated successfully, but these errors were encountered: