{"action":"created","issue":{"url":"https://api.github.com/repos/KhronosGroup/MoltenVK/issues/163","repository_url":"https://api.github.com/repos/KhronosGroup/MoltenVK","labels_url":"https://api.github.com/repos/KhronosGroup/MoltenVK/issues/163/labels{/name}","comments_url":"https://api.github.com/repos/KhronosGroup/MoltenVK/issues/163/comments","events_url":"https://api.github.com/repos/KhronosGroup/MoltenVK/issues/163/events","html_url":"https://github.com/KhronosGroup/MoltenVK/issues/163","id":324719636,"node_id":"MDU6SXNzdWUzMjQ3MTk2MzY=","number":163,"title":"vkMapMemory and vkBindImageMemory call ordering issue","user":{"login":"ch45er","id":2048216,"node_id":"MDQ6VXNlcjIwNDgyMTY=","avatar_url":"https://avatars3.githubusercontent.com/u/2048216?v=4","gravatar_id":"","url":"https://api.github.com/users/ch45er","html_url":"https://github.com/ch45er","followers_url":"https://api.github.com/users/ch45er/followers","following_url":"https://api.github.com/users/ch45er/following{/other_user}","gists_url":"https://api.github.com/users/ch45er/gists{/gist_id}","starred_url":"https://api.github.com/users/ch45er/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ch45er/subscriptions","organizations_url":"https://api.github.com/users/ch45er/orgs","repos_url":"https://api.github.com/users/ch45er/repos","events_url":"https://api.github.com/users/ch45er/events{/privacy}","received_events_url":"https://api.github.com/users/ch45er/received_events","type":"User","site_admin":false},"labels":[{"id":743503586,"node_id":"MDU6TGFiZWw3NDM1MDM1ODY=","url":"https://api.github.com/repos/KhronosGroup/MoltenVK/labels/bug","name":"bug","color":"ee0701","default":true},{"id":864831442,"node_id":"MDU6TGFiZWw4NjQ4MzE0NDI=","url":"https://api.github.com/repos/KhronosGroup/MoltenVK/labels/fixed%20-%20please%20test%20&%20close","name":"fixed - please test & close","color":"33aa3f","default":false}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":2,"created_at":"2018-05-20T15:56:25Z","updated_at":"2018-06-08T07:42:31Z","closed_at":null,"author_association":"NONE","body":"Hi,\r\n\r\nI am observing a problem while uploading image data to the GPU.  My case is as simple as to create a linearly-tiled image with host-writable and host-coherent backing memory; then to copy the pixel data and to draw some textured geometry. Pretty much the same as the well-known LunarG cube demo does.\r\n\r\nIf I do the work in the following order:\r\n1. vkCreateImage\r\n2. vkAllocateMemory\r\n3. vkBindImageMemory\r\n4. vkMapMemory + copy + vkUnmapMemory\r\n\r\neverything works as expected. However, if I swap calls 3 and 4, so that the `map+copy+unmap` sequence appears *before* vkBindImageMemory, the result is completely black image.\r\n\r\nI've tested both ways on a Windows+GTX1070 machine with 'native' Vulkan and had no issues whatsoever. According to the specs, there seems to be no ordering requirements for these calls. \r\n\r\nThis [gist](https://gist.github.com/ch45er/830e4baf96c7cb88f87c54beb801c9f9) illustrates the change and may be used to reproduce the issue using the cube demo. Points of interest are marked with `POI` in comments.\r\n\r\nThis doesn't seem to happen with buffers, except texel buffers, which are apparently backed with images in MoltenVK.\r\n\r\nI am using MoltenVK ver. 1.0.3 (bundled with LunarG SDK (vulkansdk-macos-1.1.73.0)), macOS 10.13.4. Hardware: MacBook Pro (Mid 2015) with Intel Iris Pro.\r\n\r\nAn easy way to encounter such a problem is to allocate resource memory via [VulkanMemoryAllocator](https://github.com/GPUOpen-LibrariesAndSDKs/VulkanMemoryAllocator) by calling vmaCreateImage and passing VmaAllocationCreateInfo with VMA_ALLOCATION_CREATE_MAPPED_BIT flag. This will cause the memory to be mapped before it is bound to the VkImage. "},"comment":{"url":"https://api.github.com/repos/KhronosGroup/MoltenVK/issues/comments/395677416","html_url":"https://github.com/KhronosGroup/MoltenVK/issues/163#issuecomment-395677416","issue_url":"https://api.github.com/repos/KhronosGroup/MoltenVK/issues/163","id":395677416,"node_id":"MDEyOklzc3VlQ29tbWVudDM5NTY3NzQxNg==","user":{"login":"ch45er","id":2048216,"node_id":"MDQ6VXNlcjIwNDgyMTY=","avatar_url":"https://avatars3.githubusercontent.com/u/2048216?v=4","gravatar_id":"","url":"https://api.github.com/users/ch45er","html_url":"https://github.com/ch45er","followers_url":"https://api.github.com/users/ch45er/followers","following_url":"https://api.github.com/users/ch45er/following{/other_user}","gists_url":"https://api.github.com/users/ch45er/gists{/gist_id}","starred_url":"https://api.github.com/users/ch45er/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ch45er/subscriptions","organizations_url":"https://api.github.com/users/ch45er/orgs","repos_url":"https://api.github.com/users/ch45er/repos","events_url":"https://api.github.com/users/ch45er/events{/privacy}","received_events_url":"https://api.github.com/users/ch45er/received_events","type":"User","site_admin":false},"created_at":"2018-06-08T07:42:31Z","updated_at":"2018-06-08T07:42:31Z","author_association":"NONE","body":"@billhollings \r\n\r\nI have an update. What is happening now:\r\n* vkAllocateMemory\r\n* vkBind*Memory\r\n* vkMapMemory + copy + vkUnmapMemory\r\n\r\nsequence works no matter if `vkBind*Memory` appears before or after `vkUnmapMemory`. \r\n\r\nBut the underlying Metal resource update actually happens upon `vkBind*Memory` or `vkUnmapMemory`.\r\n\r\nIn my case, the VkDeviceMemory has `VK_MEMORY_PROPERTY_HOST_COHERENT_BIT` set and is intended to be permanently mapped. The memory is used for resource uploading and staging resources are sub-allocated from it. Since the memory is host coherent, I expect any writes to that memory to be instantly visible to the forthcoming commands (e.g. vkCmdCopyImage) as the spec says: \"the host cache management commands [...] are not needed to flush host writes to the device\".\r\n\r\nWhat I am seeing however, is that synchronization is required with MoltenVK.\r\n\r\nIn the modified cube demo case, the writes are implicitly flushed by either `vkBind*Memory` or `vkUnmapMemory`. For example, if you \"forget\" to unmap the memory in `demo_prepare_texture_image`, you will see a completely black texture. This may be \"fixed\" though, by moving `vkBindImageMemory` down (to the second POI mark).\r\n\r\nShould I open a new issue for this? Is host coherency in Vulkan terms even possible in Metal?"}}
{"actor":{"display_login":"ch45er"}}