{"action":"created","issue":{"url":"https://api.github.com/repos/KhronosGroup/Vulkan-Docs/issues/132","repository_url":"https://api.github.com/repos/KhronosGroup/Vulkan-Docs","labels_url":"https://api.github.com/repos/KhronosGroup/Vulkan-Docs/issues/132/labels{/name}","comments_url":"https://api.github.com/repos/KhronosGroup/Vulkan-Docs/issues/132/comments","events_url":"https://api.github.com/repos/KhronosGroup/Vulkan-Docs/issues/132/events","html_url":"https://github.com/KhronosGroup/Vulkan-Docs/issues/132","id":139867527,"number":132,"title":"Synchronization is impossible to understand","user":{"login":"philiptaylor","id":131713,"avatar_url":"https://avatars.githubusercontent.com/u/131713?v=3","gravatar_id":"","url":"https://api.github.com/users/philiptaylor","html_url":"https://github.com/philiptaylor","followers_url":"https://api.github.com/users/philiptaylor/followers","following_url":"https://api.github.com/users/philiptaylor/following{/other_user}","gists_url":"https://api.github.com/users/philiptaylor/gists{/gist_id}","starred_url":"https://api.github.com/users/philiptaylor/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/philiptaylor/subscriptions","organizations_url":"https://api.github.com/users/philiptaylor/orgs","repos_url":"https://api.github.com/users/philiptaylor/repos","events_url":"https://api.github.com/users/philiptaylor/events{/privacy}","received_events_url":"https://api.github.com/users/philiptaylor/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/KhronosGroup/Vulkan-Docs/labels/bug","name":"bug","color":"fc2929"},{"url":"https://api.github.com/repos/KhronosGroup/Vulkan-Docs/labels/enhancement","name":"enhancement","color":"84b6eb"},{"url":"https://api.github.com/repos/KhronosGroup/Vulkan-Docs/labels/Resolving%20Inside%20Khronos","name":"Resolving Inside Khronos","color":"ed458b"},{"url":"https://api.github.com/repos/KhronosGroup/Vulkan-Docs/labels/Specification","name":"Specification","color":"50c355"}],"state":"open","locked":false,"assignee":{"login":"TobiasHector","id":17142760,"avatar_url":"https://avatars.githubusercontent.com/u/17142760?v=3","gravatar_id":"","url":"https://api.github.com/users/TobiasHector","html_url":"https://github.com/TobiasHector","followers_url":"https://api.github.com/users/TobiasHector/followers","following_url":"https://api.github.com/users/TobiasHector/following{/other_user}","gists_url":"https://api.github.com/users/TobiasHector/gists{/gist_id}","starred_url":"https://api.github.com/users/TobiasHector/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/TobiasHector/subscriptions","organizations_url":"https://api.github.com/users/TobiasHector/orgs","repos_url":"https://api.github.com/users/TobiasHector/repos","events_url":"https://api.github.com/users/TobiasHector/events{/privacy}","received_events_url":"https://api.github.com/users/TobiasHector/received_events","type":"User","site_admin":false},"milestone":null,"comments":5,"created_at":"2016-03-10T12:00:25Z","updated_at":"2016-03-16T21:47:00Z","closed_at":null,"body":"Maybe I'm just being dumb but, as far as I can tell, it's simply impossible to understand execution dependencies and memory dependencies from the spec.\r\n\r\nI think dependencies are an extremely important thing for an application developer to understand and get right - otherwise their code may work fine when they test it, but suffer from bizarre bugs when a new GPU or a new driver version is released that tries to extract more parallelism or has more aggressive caching. That'll be a huge pain for application developers and end users, and/or will prevent driver developers from adding valid optimisations that will break buggy applications (i.e. all applications).\r\n\r\nMaybe developers will learn from books and tutorials and best practices documents rather than from the spec, but the spec needs to provide a clearly-defined unambiguous foundation that other people can build a more intuitive understanding on top of. I believe it currently fails at that.\r\n\r\nI've tried to understand it myself based on what I think the spec is saying or trying to say - I'm uncertain about a lot of things around the edges, and obviously I could still be getting it fundamentally wrong, but I haven't seen anything that convincingly contradicts my basic understanding yet, so for now I'll assume that I basically get it. In that case, it seems like everybody gets dependencies wrong in practice, including all sample programs (see #128) and the WSI spec (see #131), so the misunderstanding is a widespread problem.\r\n\r\n(I should note that I'm not trying to be mean about the spec authors, it's clearly a non-trivial task especially when there's deadlines and constantly-evolving requirements and so on, so you have my sympathies! But it still needs fixing.)\r\n\r\n---\r\n\r\nI don't want to just list individual problems with the spec, because I don't think lots of small incremental changes will lead to a satisfactory result. But I see some general themes:\r\n\r\n* Some terms are used without defining them, so you have to guess from the context. (E.g. \"framebuffer-space stages\", \"side effects\".)\r\n* Some terms are used inconsistently, so it's not even possible to clearly define them. (E.g. \"region\" is described as a single pixel \"(x,y,layer)\", but is also described as having a size.)\r\n* There are many references to \"before\", \"after\", \"preceding\", \"subsequent\", \"between\", etc, which have very different meanings in different contexts, and none of those meanings are defined.\r\n* Closely-related requirements about execution/memory dependencies are spread across many different sections of the spec, so it's hard to get a coherent view of the whole thing.\r\n* Sometimes a single requirement is stated twice in two different places in slightly different ways, and you can't tell which is more correct.\r\n* Sometimes the intention behind a part of the spec seems obvious, but a literal reading gives a completely different interpretation that just seems wrong. (E.g. I think \"SetEvent(); WaitEvents(); ResetEvent(); SetEvent(); WaitEvents()\" is specified to create circular dependencies, so you can only safely use an event once per queue for its whole lifetime, making reset useless.)\r\n* The underlying conceptual model is never properly explained and has to be reverse-engineered from the text, so it's always hard to tell if you've got the right conceptual model yet.\r\n* Because the text is convoluted and open to interpretation, it's hard to report bugs in applications/drivers/spec so that everyone agrees there's even a problem instead of getting bogged down in debating quotes from the spec.\r\n\r\n---\r\n\r\nWhile I was trying to understand this, I had a go at writing (part of) the rules in a very different form, at https://github.com/philiptaylor/vulkan-sync/blob/master/README.md . I think the existing spec is essentially just defining a DAG of execution dependencies, so I made that much more explicit, and tried to be careful about defining any potentially-unclear terms. It's not necessarily easy to read but it should be possible to convey most of the meaning visually through diagrams (since DAGs are easy to visualize), and a reader can do a 1:1 translation from the diagrams back into specific rules to confirm their interpretation. I don't know if that's a successful approach or worth continuing, and it's still incomplete and buggy and would need a lot more work, but I think at least it's a lot less ambiguous and might suggest a useful direction."},"comment":{"url":"https://api.github.com/repos/KhronosGroup/Vulkan-Docs/issues/comments/197562535","html_url":"https://github.com/KhronosGroup/Vulkan-Docs/issues/132#issuecomment-197562535","issue_url":"https://api.github.com/repos/KhronosGroup/Vulkan-Docs/issues/132","id":197562535,"user":{"login":"pimanttr","id":5993936,"avatar_url":"https://avatars.githubusercontent.com/u/5993936?v=3","gravatar_id":"","url":"https://api.github.com/users/pimanttr","html_url":"https://github.com/pimanttr","followers_url":"https://api.github.com/users/pimanttr/followers","following_url":"https://api.github.com/users/pimanttr/following{/other_user}","gists_url":"https://api.github.com/users/pimanttr/gists{/gist_id}","starred_url":"https://api.github.com/users/pimanttr/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/pimanttr/subscriptions","organizations_url":"https://api.github.com/users/pimanttr/orgs","repos_url":"https://api.github.com/users/pimanttr/repos","events_url":"https://api.github.com/users/pimanttr/events{/privacy}","received_events_url":"https://api.github.com/users/pimanttr/received_events","type":"User","site_admin":false},"created_at":"2016-03-16T21:47:00Z","updated_at":"2016-03-16T21:47:00Z","body":"Just a bit later : \"The two halves of a memory dependency can either be expressed as part of a single command, or can be part of separate barriers as long as there is an execution dependency chain between them\""}}