On Wed Feb 22 15:08:30 2023 +0000, Henri Verbeet wrote:
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...) Right, I'm mostly thinking about a scenario like e.g. OSGN/OSG1/OSG5 or SHDR/SHEX.
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've pushed a v2, how's that?
FWIF, I agree it makes sense to include the tag and version fields.