Giovanni Mascellani (@giomasce) commented about libs/vkd3d-shader/spirv.c:
unsigned int component_count = vsir_write_mask_component_count(write_mask); + enum vkd3d_data_type data_type = reg->data_type; uint32_t values[VKD3D_VEC4_SIZE] = {0}; unsigned int i, j;
assert(reg->type == VKD3DSPR_IMMCONST);
- if (reg->dimension == VSIR_DIMENSION_SCALAR) + if (data_type_is_64_bit(data_type)) + { + /* SplitDouble bitcast. */ + assert(component_count <= 2); + values[0] = reg->u.immconst_u64[0]; + values[1] = reg->u.immconst_u64[0] >> 32; + data_type = VKD3D_DATA_UINT; + }
I'm not sure this is the right solution. The instruction generated by the DXIL frontend is this: ``` mov sr1.xy <v4:uint>, d(1.3300000000000001e+01l) <s:double> ``` This instruction seems to have all the information it needs to be correctly interpreted, without having to force the source register to be IMMCONST while it clearly contains a 64 bit constant. I rather think that the MOV handler should take into account the type width mismatch and do the repacking at that level. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/675#note_62646