Compute not working on MacOS for discrete GPUs

[freesig]

Looks like there is something up with the compute pipeline on for discrete GPUs on MacOS

[MacTuitui]

After some testing, I have reached the following status:

• vulkano's basic-compute-shader fails (that is, the input stays the same) on my Radeon Pro 560, but works on the next available device (the Intel one)
• on a different mac (with a GeForce GT 650M) the same issue happens
• raw vulkan examples ( https://github.com/brenwill/Vulkan ) using MoltenVK work as expected on the Radeon, especially the MVK_computeparticles one

This then suggests something is wrong with vulkano.

(This also applies to #352 as it uses a compute shader)

[freesig]

Putting notes here:

• HIGH PRIORITY vulkano memory types is VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT | VK_M EMORY_PROPERTY_HOST_VISIBLE_BIT | VK_MEMORY_PROPERTY_HOST_CACHED_BIT working is VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT | VK_ME MORY_PROPERTY_HOST_VISIBLE_BIT | VK_MEMORY_PROPERTY_HOST_COHERENT_BIT | VK_MEMORY_PROPERTY_HOST_CACHED_BIT This is set at vkAllocateMemory: memoryTypeIndex
• vulkano calls vkDestroyShaderModule right after vkCreateComputePipelines Not sure if this could cause an issue.
• vulkano makes the buffer with ALL usage bits. Working does just VK_BUFFER_USAGE_STORAGE_BUFFER_BIT
• vulkano buffer size is 262144 bytes. Working is 122880000 bytes
• vulkano pQueuePriorities[0]: const float = 0.5 working pQueuePriorities[0]: const float = 1
• vulkano pEnabledFeatures has a bunch of things enables. Working doesnt
• In the working example memory isn't mapped until the end but it is bound at the start. Vulkano maps because it's example is writing to memory first. Should try and replicate this in the working example.
• Mapped memory size in vulkano is 8388608 bytes. Note this is much bigger then the allocated size. Could try making it smaller. (or bigger to break the working example)
• vkInvalidateMappedMemoryRanges is never called in the working example
• HIGH PRIORITY From the spec:

If a range of non-coherent memory is written by the host and then invalidated without first being flushed, its contents are undefined.

Note that in vulkano it is flushed after the invalidate call. This means that we are making the memory undefined because the host is writing to the memory then we invalidate it (Like we would if device wrote to it)
I think the issue here is Invalidate and Flush are called anytime a read or write happens regardless of whether it's device or host. We should be more intelligent about this.
This is actually ok because the write is happening after the invalidate call. Same with the read

• vulkano in vkCreateDescriptorPool sets VK_DESCRIPTOR_POOL_CREATE_FREE_DESCRIPTOR_SET_BIT flag and maxSets to 40 where working has no flags and maxSets to 1
• vulkano in vkCreateCommandPool sets VK_COMMAND_POOL_CREATE_RESET_COMMAND_BUFFER_BIT flag, working sets none
• vulkano has dispatch of x: 1024 y: 1 z: 1, working has x: 100, y: 75, z: 1
• vulkano vkWaitForFences timeout is 18446744073709551615 Might overflow. Working is 100000000000
• HIGH PRIORITY Memory stays mapped the whole time in vulkano, this isn't the case in working. Try making it so.