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.
We currently check for TAG_DXBC and version 1 anyway, though. I guess that could change, but...
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.
I suppose. I don't feel strongly about the version field, I just figured I'd put the question up at least.
The DXBC tag field does seem a little silly though, if only because a DXBC shader that doesn't begin with DXBC magic sounds to me like "not a DXBC shader". (On the other hand, that kind of thing has happened before, so maybe that's a specious objection...)
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?
I don't think it'd cost us anything to commit to it, at least.
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.
Ah, of course. I was blithely assuming we'd return the checksum without validating it, but I didn't actually check.
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?
You're right, I'm just completely blind. Sorry about that.