Giovanni Mascellani (@giomasce) commented about libs/vkd3d-shader/dxil.c:
instruction_dst_param_init_ssa_vector(ins, VKD3D_VEC4_SIZE, sm6);}
+static void sm6_parser_emit_dx_split_double(struct sm6_parser *sm6, enum dx_intrinsic_opcode op,
const struct sm6_value **operands, struct function_emission_state *state)+{
- struct vkd3d_shader_instruction *ins = state->ins;
- struct vkd3d_shader_src_param *src_param;
- vsir_instruction_init(ins, &sm6->p.location, VKD3DSIH_MOV);
- src_param = instruction_src_params_alloc(ins, 1, sm6);
- src_param_init_from_value(src_param, operands[0]);
- src_param[0].reg.data_type = VKD3D_DATA_UINT;
Hmm, I'm not completely convinced here. This amounts to saying that the cast from `double` to `uint2` is done when reading from the register, and then MOV merely forwards the `uint2`. I'd rather decide that reading the register produce a `double`, which is then casted to `uint2` along the MOV instruction.
This is probably somewhat related to the discussion in https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/550 (on whether to access TEMPs and SSAs as scalar or vec4) and some discussion, mostly happened on IRC I believe, about how to represent swizzles for 64 bit types in VSIR. I don't think I have a full opinion yet, but I feel there should be some discussion.