On Mon Jan 16 23:48:54 2023 +0000, Henri Verbeet wrote:
I'm not necessarily opposed to this, but like Zeb, this does make me a bit uneasy. (And hence the delay in review.) Part of the consideration is that HLSL compiler output may be stored and is potentially long-lived. The main questions I have at this point are the following:
- Concretely, how much time do you estimate implementing this properly
would take?
- Technically, wouldn't we need to work out casting rules anyway? This
would affect what is considered valid HLSL input in the first place, not just what bytecode we end up producing for valid inputs.
2. My understanding is that, for purposes of type checking, minimum precision types are exchangeable with their regular counterparts.
So, if this assessment is correct, we won't be accepting incorrect HLSL input. We would be missing adding the minimum-precision markers on the instruction registers in the SM4 output though.
The problem I mentioned regarding casting rules is to determine what is the result type of operations between minimum precision types and regular types, or which operations, if any, discard the minimum precision information. As far as I know, the only way of checking this, for now, would be manual inspection.
Another potential problem with this workaround, is that we are also using regular types on the buffer definitions. Although, I don't see the native compiler using different offsets or other sizes for the variables declared in the buffer.
1. We may separate the problem in several steps:
- Attempt to find general rules for the resulting types of operations with minimum-precision types. - Add all the types to `enum hlsl_base_type` and go through **all** the checks for hlsl_type->base_type in the codebase to see if and how they should be included, This includes particularly sensitive functions like `expr_common_base_type()` and `expr_common_shape()`. - We also may want to consider other approaches like keeping the bits of precision on `hlsl_type`, but there will be many parts where `ctx->builtin_types` are being used that will have to be modified. - Analyze the bit patterns of the minimum-precision markers in the output bytecode and replicate them when writing SM4, in particular `sm4_dst_from_node()` and `sm4_src_from_node()`. - Create a series of test that involve both minimum precision types and regular types, and have a quick way of comparing how the minimum precision markers propagate through the code in both the native compiler and ours.
I think it may take at least 4 weeks without counting for reviews and surprises, and the rebases. Although I would want to hear the opinion of somebody else too.