On Fri Nov 3 19:51:35 2023 +0000, Zebediah Figura wrote:
There are not really variables. There needs to be some way to have
technique blocks at top level, then fxgroup block at top level, and techniques within groups. Next and final nesting level are passes that are contained in techniques. I don't see how this can nicely fit in the type system. That's why I used void. I don't immediately see why it can't? You don't need to encode any of this in the type system. Any data that techniques have can just go in the hlsl_ir_var instead. This goes for other effect-specific objects too, probably. At least some of those act (even) more like variables. Void variables aren't bad, but slightly better for error reporting purposes would be to introduce a HLSL_TYPE_TECHNIQUE. Alternatively we could just check for a name conflict with techniques in every place that we check for a name conflict with variables. I don't know offhand how many such places there are, so I don't know how ugly this would end up being.
Ok, I can do TYPE_TECHNIQUE with CLASS_OBJECT, same for groups and passes. And later for other state types. Yes, hlsl_ir_var for group/technique/pass will need something extra in it.
It seems more sustainable to have them as regular variables so we don't need to chase conflict checks. I still think it's better to have a separate list for them and not use extern_vars. First so we don't need to filter them out for regular profiles compilation, and second so that order they appear in is stable and predictable, it's critical that order is preserved for index access. Maybe single list is already working well for that, but I think keeping effect objects slightly separately from normal shader compilation is not a bad idea.