-
Notifications
You must be signed in to change notification settings - Fork 12
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
Generalized VkStruct? #45
Comments
The funny thing is that this is exactly what |
Ah, nice! I do think breaking it off into its own library would be useful. It could be used by both easytensor and vulkan-api (if you were willing to give it a dependency). But I'm looking to make or modify a binding to assimp, and I noticed the existing one is defining simple record types and Storable instances. I realized it might be nicer to define VkStruct like things instead... |
Though, whatever was extracted into its own library would need to support arrays of structs, which is what your dataframes fundamentally are... so maybe you should have a generalized primbytes+dataframe library, and then just put tensor-specific stuff in easytensor? |
Yes, this would make sense! Except there is no tensor-specific stuff in |
Well the tensor-specific stuff is your Matrix and Vertex stuff, for example. DataFrame is more general than being used as a tensor, since it can be treated as just a typesafe array of data. At least that's how I see it currently. |
And regarding people using it outside vulkan/easytensor, it seems like it would be very useful for FFI libraries, and code using them. Besides that, I can't think of why you would need it... If you don't need a pointer to precisely laid out data, you can just use standard ADTs. |
NB: there is some duplicated functionality in |
Have you considered, or do you see any problem with, the idea of making a generalization of VkStruct, one that's not Vulkan specific? It just seems to me that the ability to read/write a byte array as a struct with named and typed fields would be useful elsewhere. Particularly in C-library bindings.
The text was updated successfully, but these errors were encountered: