Unless you meant to write "an upper bound of input_signature->element_count" [which may make more sense given your second sentence]? That'd work, though it'd be meaner to remap_output_signature().
I think I did. It shouldn't be any meaner than "output_signature->element_count + some extra stuff" though; it's a different bound, but it doesn't say anything about the order by itself. I wouldn't necessarily be opposed to specifying this as e.g. a sorted array of "{src_index, dst_index, dst_mask}" either though.
Well, the current order allows remap_output_signature() just to look up by register_index or by signature index. Either of the above options would instead require us to do a secondary loop. From a performance standpoint that may not meaningfully matter, though; I guess we're going to do that loop once *somewhere*.
I originally was going to write that, but decided that since I was indexing the array by register_index, it wouldn't work. But on reflection there's no reason we can't index the array by the *signature* index, so yeah, that'd be better.
Ugh, but the annoying thing about doing this is that I/O normalization passes reorder the signature...
I think it should only do that temporarily? shader_signature_merge() has a qsort() at the end that should restore the original order. It does of course potentially merge elements, which is perhaps just as bad.
Yeah, in theory it does, but that's not working out for some reason. I don't think I fully investigated why, but if we're messing with the signature order at all then I think we want to remap *before* doing I/O normalization. Which isn't actually ugly, I just had some amount of tunnel vision there.