[PATCH vkd3d 5/7] vkd3d-shader/hlsl: Write SM4 casts to float.

[Matteo Bruni]

On Wed, Sep 15, 2021 at 9:16 AM Giovanni Mascellani
<gmascellani at codeweavers.com> wrote:
>
> Hi,
>
> Il 10/09/21 01:16, Matteo Bruni ha scritto:
> > As far as I'm aware, booleans in SM4+ are represented in quite a
> > peculiar way: false is represented as 0, true is canonically
> > 0xffffffff. I think the idea is to be able to use the result of a
> > conditional expression directly as a mask and such, but don't quote me
> > on that. For sure it's different from SM1-3, which use the traditional
> > 0 and 1 values for false and true.
>
> Well, isn't it our choice how we decide to represent things internally?
> The only important requirement is that casts (and everything else) have
> the correct semantics. Whether inside a true bool variable there is 1,
> ~0u or whatever else it's our decision. If we store 1 for true, then we
> have to use MOVC (or a comparison followed by INEG) when casting to bool
> and MOV or ITOF when casting to int or float. If we store ~0, then we
> use a simple comparison for casting to bool and MOVC (or INEG and
> possibly ITOF) to cast to int or float.
>
> In case we want to be closer to native (though I'm not sure it's really
> a requirement in this case: I expect all this opcodes to be well
> supported everywhere), then probably choosing to represent true as ~0u
> is better, but it's just a matter of choice. The really important thing
> is to be aware and consistent with the choice.
>
> So what do we decide? I already have patches that implements comparison
> operators that assume that true is represented as 1. I can fix them, but
> please tell me what do we want.
>
> Giovanni.

Yeah, we do want to have true as ~0u for SM4+ (there is no real bool
type in < SM4, so that doesn't matter). There is no reason to do
things differently and there might be some other unexpected way for
the internal representation of true to leak in a visible manner.