On Fri Jun 2 21:25:53 2023 +0000, Zebediah Figura wrote:
Then I think I would be in favor to emit the `<resource>` as well.
I think I may have misinterpreted this comment, I assumed you were saying that you preferred the code as I wrote it? Or are you saying we should write out "<resource>" into the table instead of stripping it? If the latter—to clarify, by "not visible" I mean the "<resource>" part is never visible, that's an invention I added, basically working around code that I wasn't sure at the time could handle multiple variables with the same name (well, definitely can't, in some respects). Native does indeed have multiple variables with the same name in the RDEF table. I don't love the <resource> hack, though I still don't hate it either, and I can agree with the idea of just storing that as an extra part of the key. -- Actually, what just occurred to me: along the same lines as some of my suggestions on this merge request, I'm not even sure we need to synthesize another variable. We could just reuse *this* variable (and set some flag telling RA that we need to allocate both sampler and texture variables for it?) That does mean we need special logic around sm4_register_from_deref() [which could potentially be a simple as passing a register set to that function?], which is a bit unfortunate but maybe ultimately not that unfortunate? What do you think?
Ok, I think I understand. I think I'd prefer if we kept two names for each variable, one for internal indexing and the other to be printed out in RDEF, rather than having that special exception if `tpf.c`, but I think I can tolerate it. I might become more vocal about it, though, if in the future the practice of prepending a variable name with a `<tag>` were to become more frequent.
I'd still ask for adding some kind of `is_separeted_resource` flag to `hlsl_ir_var` rather than parsing the variable name in 9/9.