Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support multiple types of vk Buffer types like uniform, etc (beyond storage buffer) #5

Open
axsaucedo opened this issue Aug 28, 2020 · 3 comments
Labels
enhancement New feature or request triage Issue still needs to be discussed, researched and scoped

Comments

@axsaucedo
Copy link
Member

Currently the storage buffer is the only one supported, it will be important to add an extra capability for buffers of types beyond storage buffer. This will have to be an initial research to identify which types to prioritise and why.

@axsaucedo axsaucedo added enhancement New feature or request triage Issue still needs to be discussed, researched and scoped labels Aug 28, 2020
@axsaucedo
Copy link
Member Author

Currently there are several types that can be added includign UBOs, and image buffers as per #4, it will be important to find specific areas where UBOs would be more efficient, as this will be required on how it also fits the Tensor -> Params -> Algorithm components https://www.reddit.com/r/vulkan/comments/4uayoo/why_should_i_use_a_uniform_buffer_if_i_can_have_a/

@axsaucedo
Copy link
Member Author

From documentation it seems there are clear adv/disadvantages when using UBOs vs SSBOs, primarily that SSBOs can be much larger, whilst UBOs can be faster. This means it will be important to explore adding this as a simple extension to users to define the type of memory binding. https://www.khronos.org/opengl/wiki/Shader_Storage_Buffer_Object

@MiroPalmu
Copy link
Contributor

How should we implement different API for different vk Buffer types?

My proposal would be to have different kp TensorTypes. For example TensorType::eUniformBuffer etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request triage Issue still needs to be discussed, researched and scoped
Projects
None yet
Development

No branches or pull requests

2 participants