- /**
- `* The DXBC version. The only supported DXBC version in this version of`
* vkd3d-shader is 1. */
- uint32_t version;
Do we even want to bother with this? I can only imagine that if the DXBC version is ever incremented (which seems unlikely at this point), it'll be for something that'll need us to reroll struct vkd3d_shader_dxbc_desc anyway.
- /** The DXBC tag. This should always be "DXBC". */
- uint32_t tag;
Is there a point in this? This seems even less likely to change.
It's not terribly useful, no. I didn't see the harm in including it though, mostly with the idea that it would allow the (largely hypothetical at this point) vkd3d-blob program to dump the actual content of the blob instead of making something up. And while a version 2 doesn't seem terribly likely at this point, I could certainly imagine a version 2 that e.g. just has some extra fields or e.g. 64-bit offsets and sizes that should be representable with the current structure, even if it wouldn't include everything contained in the blob. That said, I don't mind dropping these if you object to them.
- \param desc A vkd3d_shader_dxbc_desc structure describing the contents of
- the DXBC blob. This structure may contain pointers into the input blob; its
- contents are only valid while the input blob is valid. The contents of this
- structure should be freed with vkd3d_shader_free_dxbc() when no longer
- needed.
Should we go farther than "may" and specify "will"? In order to be potentially more useful to the API consumer, and generally follow the principle of "be conservative in what you provide".
I had "will" originally and weakened it. I don't mind changing it back, although I'm not sure that's a guarantee we're necessarily willing to commit to?
- \param flags A set of flags modifying the behaviour of the function. No
- flags are defined for this version of vkd3d-shader, and this parameter
- should be set to 0.
I don't suppose you have anything in mind for this parameter?
I do, actually. The idea was to provide the ability to disable validation of the checksum, and possibly sizes and offsets. Again mostly for the benefit of a hypothetical vkd3d-blob program.
Wrt patch 11/11, besides the tag and version, do we want to put the onus on the user to specify the checksum and total size? (And if not, do we want to pass a whole vkd3d_shader_dxbc_desc?)
Either way, I think the documentation should be clear about it.
Perhaps I'm misunderstanding your comment, but I don't think we should, and that's why we're passing an array of sections to vkd3d_shader_serialize_dxbc() instead of a vkd3d_shader_dxbc_desc structure?