On Thu Feb 8 21:30:56 2024 +0000, Zebediah Figura wrote:
Do we really want to be defining a type rbtree like this? The existing code is explicitly set up to be usable by the backend in such a way—cf. the "bytecode_offset" member—and sm4 types (and I think also sm1) are similarly supposed to be deduplicated, we just don't because it doesn't actually matter. I'm not sure the answer is "no", mind. There's something to be said for orthogonality, and if we're going to be shoving things through vsir then we should maybe try to avoid hlsl leaking through so much. [Although on the other hand, if we're shoving things through vsir then how *do* we build reflection data? That's an unsolved question.] But I'm not sure the answer is yes either. Either way, do we really want it to be an rbtree? It doesn't seem likely we'll have enough types to matter, and rbtrees are broadly just more work to deal with than an array or list.
I don't see your point. Why not have it as an rbtree? We have it like that for the compiler. There is one compare function, init/destroy, and that's it. Regarding duplicated types, what I want is a matching binary, because it's much easier to compare this way. There should be no problem of getting it to match in metadata parts, shaders will obviously differ.