On Fri, Aug 13, 2021 at 6:00 PM Zebediah Figura (she/her) zfigura@codeweavers.com wrote:
On 8/13/21 9:03 AM, Matteo Bruni wrote:
Signed-off-by: Matteo Bruni mbruni@codeweavers.com
For reference: originally the plan was for HLSL_IR_EXPR to only cover "mathematical" expressions, or more specifically, pure expressions that could be transformed and moved around (e.g. hoisted out of a loop) without any problem. In that world statements that don't fall under that banner, like texture sampling instructions, would not be expressions.
My original setup was inspired by the Mesa GLSL frontend (at the time). It looks like NIR also followed along the same line, with what they call ALU instructions covering our expressions and intrinsic instructions basically matching everything that isn't an ALU instruction or a jump (or SSA stuff).
Now, that concept doesn't necessarily need to be preserved in the same form. We probably still need some way to separate "pure" expressions from the rest though. What's your idea in this regard?
I'm not aware of restrictions that fall on sample/load instructions that don't apply to pure mathematical expressions. What restrictions are you aware of?
Basically, you can't necessarily pull those instructions out of loops or conditionals, duplicate them when flattening conditionals, CSE them out etc. Usually those are problematic only when there are also out-of-pipeline stores (UAVs, shared memory) in the same shader. See https://people.freedesktop.org/~cwabbott0/nir-docs/instructions.html#intrins... for an overview from the NIR perspective. Confusingly, NIR intrinsic instructions are not the same thing as HLSL intrinsic functions (https://docs.microsoft.com/en-us/windows/win32/direct3dhlsl/dx-graphics-hlsl...) as the latter are simply functions predefined in HLSL, which would map to one or more NIR instructions, ALU or otherwise.
Now, maybe we don't need to make any of those "sensitive" transformations and we avoid the entire issue altogether, but it seems reasonable to be defensive and provide some way in the IR or the compiler to distinguish those instructions from the "safe" ones.