Now, I could understand your desires if your goal was to send a GPU address to the shader, allow it to do some arbitrary pointer arithmetic, then cast it into an object and read from that memory. But in the grand scheme of things, I think that's going to be a pretty minor problem. Yes, this read may well be an uncached read, so in a hot loop, an extra uncached read can be a problem. The only thing that needs to happen is getting the GPU address out of the VkBuffer, which should be nothing more than a memory read. Buffer storage will never be moved around, ever. Vulkan doesn't do validation, so none of that happens. A VkBuffer is a pointer directly to the implementation's data structure, so no conversion from an integer to a pointer needs to happen. Lastly, it converts the buffer to a GPU address, which is then sent to the GPU to do its work.īut in Vulkan, almost none of that happens. Also, the implementation needs to check to see if the buffer object's storage has been or needs to be moved around. Any validation that fails results in a GL error. It has to do validation work for example, it has to make sure that the buffer + offset does not exceed the size of the buffer. It has to convert the buffer object name into an actual buffer object pointer. When you attach a buffer to a VAO or bind it to the context in a uniform buffer slot, and then try to render, the implementation has to do a number of things, only some of which is required by the hardware. I understand why they matter in OpenGL it's because of aspects of the OpenGL API. My issue is understanding why bindless vertex/uniform buffers matter. I at least theoretically understand the bindless texture concerns, though jeffbolznv made it clear that most implementations of bindless are just using tables behind the scenes, so there's no overhead lost by you maintaining the table yourself. I find this list partially perplexing, given your "perceived overhead" issue. That's already supported in VK_EXT_descriptor_indexing (see also UBOs, bindless vertex buffers, and most importantly bindless textures as well. This was a big feature request for portability from D3D12, where applications have that similar control.Īn optional capability to do divergent dynamic indexing because the ARB bindless texturing variant had that annoying limitation On the other hand, one of the benefits of the descriptor_indexing model is that the app has control over placement of related textures in the descriptor set, so that a single index can be used to select multiple textures. So I don't see what the perceived benefit of the ARB extension is. Is the perceived overhead the cost of binding it once, or of accessing the resource through a descriptor set?ĪFAIK all implementations of ARB/NV_bindless_texture used a table of descriptors behind the scenes, and were ultimately not much different than going through a descriptor set. What is the perceived overhead? You only ever need to bind it once. We don't want to deal with binding everything to a descriptor set since it adds additional overhead.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |