{"action":"created","issue":{"url":"https://api.github.com/repos/gpuweb/gpuweb/issues/48","repository_url":"https://api.github.com/repos/gpuweb/gpuweb","labels_url":"https://api.github.com/repos/gpuweb/gpuweb/issues/48/labels{/name}","comments_url":"https://api.github.com/repos/gpuweb/gpuweb/issues/48/comments","events_url":"https://api.github.com/repos/gpuweb/gpuweb/issues/48/events","html_url":"https://github.com/gpuweb/gpuweb/issues/48","id":297278947,"number":48,"title":"[meta] Big questions","user":{"login":"kvark","id":107301,"avatar_url":"https://avatars1.githubusercontent.com/u/107301?v=4","gravatar_id":"","url":"https://api.github.com/users/kvark","html_url":"https://github.com/kvark","followers_url":"https://api.github.com/users/kvark/followers","following_url":"https://api.github.com/users/kvark/following{/other_user}","gists_url":"https://api.github.com/users/kvark/gists{/gist_id}","starred_url":"https://api.github.com/users/kvark/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/kvark/subscriptions","organizations_url":"https://api.github.com/users/kvark/orgs","repos_url":"https://api.github.com/users/kvark/repos","events_url":"https://api.github.com/users/kvark/events{/privacy}","received_events_url":"https://api.github.com/users/kvark/received_events","type":"User","site_admin":false},"labels":[{"id":536258994,"url":"https://api.github.com/repos/gpuweb/gpuweb/labels/question","name":"question","color":"cc317c","default":true}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":1,"created_at":"2018-02-14T23:12:05Z","updated_at":"2018-02-21T15:31:23Z","closed_at":null,"author_association":"NONE","body":"List of big questions to resolve for the content of the API (not the shape):\r\n  1. **resource allocation**\r\n      - how are resources bound to memory\r\n      - whether memory heaps are exposed or implied\r\n  2. **resource capabilities** - #37\r\n      - do we ask the user for the set of potential usages for each resource (akin [D3D12_RESOURCE_FLAGS](https://msdn.microsoft.com/en-us/library/windows/desktop/dn986742(v=vs.85).aspx)) or imply this\r\n  3. **multiple queues**\r\n      - do we expose multiple hardware queues (limited in Vulkan, unlimited in D3D12) or try to parallelize in the driver itself (like Metal)\r\n  4. **memory barriers**- #27:\r\n      - choices: implicit, half-explicit (with only the destination state provided), fully explicit (Vulkan, D3D12)\r\n  5. **partial pipeline states**\r\n      - do we create blend, depth-stencil, raterizer (and other) states independently, or only as a part of a bigger pipeline state?\r\n      - support for non-dynamic states (Vulkan only)\r\n  6. **tile memory**\r\n      - do we take advantage of tiled renderers?\r\n      - existing APIs: tile memory in Metal, multiple sub-passes in Vulkan\r\n      - blocked by D3D12\r\n  7. **data upload/download** - #45\r\n      - persistent mapping support\r\n      - coherency\r\n      - callbacks versus polling\r\n  8. **web workers support**\r\n      - resource creation\r\n      - command buffer recording\r\n  9. **shader languages** - #42,#43,#44:\r\n      - consume SPIR-V and/or HLSL\r\n      - support for pipeline/shader caches\r\n  10. **DOM integration**\r\n      - swapchain initialization, frame sync\r\n      - canvas/OffscreenCanvas interop\r\n      - WebXR integration\r\n      - video elements, image elements, etc.\r\n  11. **security == portability** (~~N==NP~~):\r\n      - is there a portability trade-off with performance that we can take without compromising the security?"},"comment":{"url":"https://api.github.com/repos/gpuweb/gpuweb/issues/comments/367364417","html_url":"https://github.com/gpuweb/gpuweb/issues/48#issuecomment-367364417","issue_url":"https://api.github.com/repos/gpuweb/gpuweb/issues/48","id":367364417,"user":{"login":"kvark","id":107301,"avatar_url":"https://avatars1.githubusercontent.com/u/107301?v=4","gravatar_id":"","url":"https://api.github.com/users/kvark","html_url":"https://github.com/kvark","followers_url":"https://api.github.com/users/kvark/followers","following_url":"https://api.github.com/users/kvark/following{/other_user}","gists_url":"https://api.github.com/users/kvark/gists{/gist_id}","starred_url":"https://api.github.com/users/kvark/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/kvark/subscriptions","organizations_url":"https://api.github.com/users/kvark/orgs","repos_url":"https://api.github.com/users/kvark/repos","events_url":"https://api.github.com/users/kvark/events{/privacy}","received_events_url":"https://api.github.com/users/kvark/received_events","type":"User","site_admin":false},"created_at":"2018-02-21T15:31:23Z","updated_at":"2018-02-21T15:31:23Z","author_association":"NONE","body":"Got some detailed feedback from @zeux on some of the big questions. Arseny Kapoulkine has a great deal of experience in low-level graphics optimization of Vulkan and Metal-1 on both mobile and desktop.\r\n> At Roblox we have a pretty carefully optimized renderer that uses Metal & Vulkan; we don't necessarily strongly favor one or the other.\r\n\r\n####  1. resource allocation\r\n> allocation performance has been very much an issue for us in both Metal and DX11, and has been a non-issue in Vulkan. In Vulkan we know allocations are slow, but they also can be large and we can easily suballocate and manage our own memory - crucially, without conflating the lifetime of individual objects sharing the space or having to worry much about compatibility requirements\r\n> FWIW we don't have separate codepaths for Vulkan for NV/etc. - we just have generic code that looks at available memory types and picks the one that the driver exposes that matches our requirements for the resource. We do have special cases for devices that expose device-local&host-available mode (mobile/unified memory), but otherwise we just deal with whatever the driver throws at us.\r\n\r\nThus, we need some sort of heap allocation for resources. Whether it's restricted as Metal or free-style as Vulkan is up for discussion.\r\n\r\n#### 3. multiple queues\r\n> as far as I understand is impossible in Metal to this day is compute overlap (e.g. having several compute dispatches read & write the same resource concurrently, provided that the application guarantees lack of race conditions) - we had some prototypes for algorithms where this was significant for GPU performance (double-digit percentages), but that should be possible to achieve in Metal with small API tweaks, similar to how NV/AMD have extensions for this in DX11\r\n\r\nThus, we either need to figure out what those \"small API tweaks\" are, or expose multiple queues like D3D12/Vulkan. A follow up question to Apple - any idea on why Metal driver can't do async compute?\r\n\r\n#### 4. memory barriers\r\n> While explicit barriers in Vulkan allow the app to implement any management strategy it desires to cut down on the CPU/GPU cost, they are way more complicated than what would be ideal for an explicit design. They are hard to understand, hard to reason about, lots of people get them wrong - including in vendor SDK samples, sometimes vendor articles, etc. - *and* validation layers don't validate their correctness at all at this time. Whether explicit or implicit barriers are better is debatable, for explicit barriers I would definitely recommend the resource state model, as used by DX12 and for example this library https://github.com/Tobski/simple_vulkan_synchronization (I believe the author had a significant part in the barrier design in Vulkan, the fact that he made this library might be telling :D). DX12 does get some things wrong, such as lack of UNDEFINED state transitions and potentially insufficient state coverage as applicable to tilers, but the model itself is much simpler. This is a big factor in both reducing application complexity, and reducing potential for driver bugs - we definitely have seen Vulkan bugs where drivers misinterpreted the (valid) barrier setup as well.\r\n\r\nTL;DR: we don't have any performance data on the effectiveness of explicit barriers, but we know that they are super hard to get right.\r\n\r\n#### 9. shader languages\r\n> our shaders are written in HLSL; our shader translation pipeline is slowly moving towards being entirely SPIRV based for GL/Metal/Vulkan\r\n\r\nThis info doesn't show us a way forward, but at least confirms that we are on the right track :)\r\n\r\n#### (unlisted) resource binding - #19\r\n> For draw call cost in general, Vulkan binding model *should* have an advantage compared to Metal for some architectures in terms of CPU update cost - Metal uses per-stage indexed bindings, which doesn't really match AMD designs for one, and requires driver to shadow a lot of that state and build actual HW descriptors at draw call time. There are a lot of other design decisions in Vulkan that allow to reduce binding cost further in the driver, for example buffer object descriptors can - on some hardware - be packed into the 64-bit object handle which means that when you update the descriptors, the driver can copy handles from your memory into, say, GPU memory or registers, without any cache misses that are required in Metal model - unless you group all your buffer objects into very few very big ones. Again, future Metal revisions try to improve on this significantly, specifically with Metal 2's argument buffers, but we haven't used them so can't comment on viability\r\n\r\nThis confirms our choice of binding model to be a good. Experiments in gfx-rs have also confirmed that Metal 2's argument buffers can serve as an efficient backend implementation, when available.\r\n\r\n---\r\nOk, I think this captures the essence of Arseny's feedback (thank you!). Please feel free to correct me or add more info. I tried to stay objective and communicate information that is most helpful for the group to move forward, not necessarily aligning with Mozilla's prototype. The conclusions I drew are up for debate, and we'll surely need detailed feedback from other ISVs in order to make a good judgement."}}
{"actor":{"display_login":"kvark"}}