On Thu, Jan 20, 2022 at 6:51 PM Zebediah Figura (she/her) zfigura@codeweavers.com wrote:
On 1/20/22 06:12, Matteo Bruni wrote:
On Thu, Jan 20, 2022 at 12:42 AM Zebediah Figura (she/her) zfigura@codeweavers.com wrote:
On 1/19/22 06:03, Matteo Bruni wrote:
On Mon, Dec 20, 2021 at 10:44 PM Zebediah Figura (she/her) zfigura@codeweavers.com wrote:
On 12/20/21 12:15, Zebediah Figura (she/her) wrote:
On 12/19/21 06:41, Nikolay Sivov wrote: > +static struct hlsl_ir_node *intrinsic_float_convert_arg(struct > hlsl_ctx *ctx, > + const struct parse_initializer *params, struct hlsl_ir_node > *arg, const struct vkd3d_shader_location *loc) > +{ > + struct hlsl_type *type = arg->data_type; > + > + if (type->base_type == HLSL_TYPE_FLOAT || type->base_type == > HLSL_TYPE_HALF) > + return arg;
add_implicit_conversion() already does this.
Sorry, turns out I'm wrong; this preserves the input type for half, whereas add_implicit_conversion() alone would not.
I wonder if that's what it should do in the first place?
Yes, witness the following shader:
uint func(float x) { return 1; } uint func(half x) { return 2; }
float4 main(void) : sv_target { return float4(func(float(0)), func(half(0)), func(int(0)), func(uint(0))); }
Native reduces this to (1, 2, 1, 1).
Fun... But at least it means we can fix add_implicit_conversion() and avoid that kind of workarounds, if I understand correctly.
I... guess, but it seems janky. The main point of add_implicit_conversion() is for stuff like assignment RHS or return values. If we had add_implicit_conversion() pass through half it'd generate IR like
2: half | 1.0 3: | x = @2 4: float | x
(i.e. "x" is a float variable). Which... works, I guess? Maybe it's not that bad, since we already do a somewhat similar thing for scalar vs vec1.
I think that's an improvement to the current state of things, right now we're effectively losing information from the get-go. We can always add a half-to-float lowering pass to simplify the IR.