GitLab

Originally this field didn't have any bitsize information. However, later types were added to some load/store intrinsics, and setters of those add a bitsize which always matches the size of the data SSA value/register, which made nir_tex_instr inconsistent. However the real mess was created when adding support for mediump, as glsl-to-nir just made fp16 and int16 destinations have a sized dest_type but kept the unsized type for the old 32-bit destinations. This meant that e.g. nir_type_float now actually meant nir_type_float32, so the shed was now painted half-red and half-green with some ugly mixture in the middle, and various backends have various workarounds for the situation. Further confusing things was that the new CL image-to-sampler lowering pass was even more (in)consistent, using sized types for everything.

This series untangles the resulting mess. I decided to go with sized types, as even though it's redundant it seems to be what backends that actually care want, and so it makes backends ever-so-slightly simpler, in addition to being consistent with what we're doing with intrinsics. First we update the few places that were inspecting the type and explicitly using e.g. nir_type_float, making them accept both sized and unsized types temporarily so that we can update everything piecemeal. Then we update all creators of nir_tex_instr to use sized types. The annoying part is that this includes everyone's home-baked blit shader, of which there are quite a lot. After this is done, we update nir_validate to make sure that we got it right and make sure it stays right, at which point we can finally get rid of the scaffolding we introduced at the beginning and make a few other simplifications. I think there are probably room for more simplifications in the dxil backend, but I'll let someone else handle that.