Compute shader shader example doesn't perform compute on mac
- Version of vulkano:
vulkano = "0.11"
vulkano-shaders = "0.11"
vulkano-win = "0.11"
- OS: Mac OS X Mojave
- GPU (the selected PhysicalDevice): GT750M
- GPU Driver: Vulkan Instance Version: 1.1.92
- Upload of a reasonably minimal complete
main.rsfile that demonstrates the issue: see basic-compute-shader.rs in the vulkano-examples repository.
Issue
The example runs but does does not return 12 as expected. Instead it returns 1. The computer shader does not perform the multiply operation.
Thanks for the issue, I don't have macOS so I cant test or investigate the issue myself.
Can you try enabling validation layers: VK_INSTANCE_LAYERS=VK_LAYER_LUNARG_standard_validation cargo run --bin basic-compute-shader --release And then post anything it outputs.
Also try adding std::thread::sleep(std::time::Duration::from_millis(50000)); before let data_buffer_content = data_buffer.read().unwrap();
I'm also getting this bug. I tried your suggestion @rukai but it still returns 1 instead of 12. I have:
OS: Mac OS X Mojave
Intel(R) Iris(TM) Graphics 6000
Vulkan Instance Version: 1.1.92
So I'm having a similar problem aswell with the first example in the guide. It doesn't swap the buffers. So I adapted a minimal c++ example to do the same thing here. It does work on my system. Then I cloned vulkano and put a print in the vulkan-sys calls so I could see exactly what calls the example was making. Output is here: output.txt
I'm working through the differences in the calls and my minimal c++ example. I'm pretty new to Vulkan but hopefully this helps.
So far the only thing I've noticed that is different is the way the memory is mapped and unmapped.
So I'm having a similar problem aswell with the first example in the guide. It doesn't swap the buffers. So I adapted a minimal c++ example to do the same thing here. It does work on my system. Then I cloned vulkano and put a print in the vulkan-sys calls so I could see exactly what calls the example was making. Output is here: output.txt
I'm working through the differences in the calls and my minimal c++ example. I'm pretty new to Vulkan but hopefully this helps.
So far the only thing I've noticed that is different is the way the memory is mapped and unmapped.
Thanks for that example. I will use your example as a reference.
I've started building a debug module that also prints out the parameters of each call. It's a little slow to do because each parameter needs to be converted from raw c structs and pointers to something I can print in rust.
Today I checked MapMemory, CreateInstance and CreateDevice.
The only one that is different so far is CreateDevice. The queueCreateInfoCount is 0. Compared to my c++ example it is 1.
Interesting find! Here are the docs for VkDeviceQueueCreateInfo struct.
queueCount is an unsigned integer specifying the number of queues to create in the queue family indicated by queueFamilyIndex.
That definitely sounds like it should be at least 1! I wonder if for some reason one of the first queue_families returned on your system has no usable queues in it? Perhaps it's worth adding a filter that checks that there's at least one queue to this line (or the equivalent line in the example you're testing)?
@freesig just for the record @JoshuaBatty just updated MoltenVK from 1.1.82.1 to 1.1.92.1 and now seems to be getting the same issue as is happening here.
The queueCreateInfoCount was a me printing a variable wrong. It's actually the same. In fact every single call and parameter is now exactly the same between the two examples. I still get a proper result with the c++ example and all 0's with the vulkano.
I think it must be something to do with how the memory is mapped / read. For example maybe there's been an update to MoltenVK that means the memory mapping doesn't last as long and is no longer active when we read or something.
I'll starting digging into the read and see what I can find.
Actually I take that back. All the calls are the same to vulkan but the way I was reading the memory was different. Now that I read it the same way I get the same results on both examples.
I'm pretty new to this so maybe I'm not understanding the purpose of the buffers but:
In vulkano you allocate a big region of VkDeviceMemory then bind two VkBuffer to that device memory.
However as far as I can tell the reading / writing from / to the VkDeviceMemory is just done with void * and offsets.
What is the purpose of the VkBuffer? Is it sort of a handle to a region of VkDeviceMemory so that you can tell vulkan what region you are talking about?
If so I think something is going wrong with how MoltenVK thinks about VkBuffer.
It looks like the vkCmdCopyBuffer has no affect.
But before I had the src VkBuffer and the dest VkBuffer mapped to different VkDeviceMemory and the vkCmdCopyBuffer did actually copy the data.
Ok so I found something that works.
Everything the same (ie. both VkBuffers pointing to the same VkDeviceMemory)
but if you:
vkMapMemory- write to src
vkUnMapMemory- copy buffers
vkMapMemory- read dest buffer
vkUnMapMemory
I think this is related https://github.com/KhronosGroup/MoltenVK/issues/175
Ok I'm also experiencing this issue https://github.com/KhronosGroup/MoltenVK/issues/377
But I realized that you can fix the above issue and the one we are having by Unmapping before any vkBindBufferMemory calls and then remapping.
So if you need to bind buffer memory do it like:
vkUnMapMemoryvkBindBufferMemoryvkMapMemory
Also seeing this issue, still, even on the latest versions of MoltenVK / Vulkano. Similar issues on other examples, everything sets up correctly, just no computation happens.
Is this with discrete or integrated GPU? or both?
I can reproduce this error on a discrete GPU.
OS: Mac 10.15.2 Beta (19C56a)
AMD Radeon Pro 560
Vulkan Instance Version: 1.1.97
https://www.phoronix.com/scan.php?page=news_item&px=MoltenVK-For-Vulkan-1.1.130
Saw this on Phoronix wonder if this solves any MacOS isseues
Is this still an issue?
Is this still an issue?
I haven’t done any molten vk stuff in a while. I won’t be able to test this until late jan.