Hello,
On 12-08-22 14:06, Zebediah Figura (she/her) wrote:
On 8/11/22 15:26, Francisco Casas wrote:
+static bool check_for_non_static_object_references(struct hlsl_ctx *ctx, struct hlsl_ir_node *instr, + void *context)
Just a suggestion, I think "validate" would be a good word to use here.
Okay, going for 'validate_static_object_references'.
+{ + unsigned int start, count; + bool invalid = false;
+ if (instr->type == HLSL_IR_RESOURCE_LOAD) + { + struct hlsl_ir_resource_load *load = hlsl_ir_resource_load(instr);
+ invalid |= !hlsl_component_index_range_from_deref(ctx, &load->resource, &start, &count); + if (load->sampler.var) + invalid |= !hlsl_component_index_range_from_deref(ctx, &load->sampler, &start, &count); + } + else if (instr->type == HLSL_IR_LOAD && instr->data_type->type == HLSL_CLASS_OBJECT) + { + struct hlsl_ir_load *load = hlsl_ir_load(instr);
+ invalid |= !hlsl_component_index_range_from_deref(ctx, &load->src, &start, &count);
Do we need this "else if" branch at all? In fact, won't this result in multiple messages if a dynamic dereference is used?
It indeed results in multiple messages. However, I think we may need both branches:
On one hand, the native compiler throws an exception on dynamic object references even if they are not used, e.g. with the following ps_5_0 shader: --- uniform int p; Texture2D tex[2];
float4 main() : sv_target { Texture2D u = tex[p]; // Not used, but throws an exception anyways.
return float4(0, 1, 2, 3); } --- which makes necessary the "else if" branch (and to do this validation pass before DCE, as we already do).
On the other hand, if we delete the "if" branch we would be introducing the assumption that for each resource load there is an object load that will trigger the error (same for samplers), which seems a little hard to remember to maintain this way if we introduce changes in the previous passes. Furthermore, I am not totally sure if it always holds true **now**.
+ }
+ if (invalid) + hlsl_error(ctx, &instr->loc, VKD3D_SHADER_ERROR_HLSL_NON_STATIC_OBJECT_REF, + "All object references must be determinable at compile time.");
I think it'd be helpful to name the specific expression that can't be resolved (and, along the same lines, to report resources and samplers separately).
Okay. I am thinking on using hlsl_note() after hlsl_error() to report the location of the expression to the user, getting outputs like: --- testm.hlsl:7:20: E5022: Loaded resource must be determinable at compile time. testm.hlsl:7:14: Expression cannot be resolved statically. --- Is this okay?
I can also print the instruction pointer as a TRACE() or similar.
+ return invalid;
Shouldn't this always return false? We don't have any more work to do.
Ah right, I wasn't following that convention. I just thought that having "invalid" as return value could be useful. I will make this function return "false" always.
+}
wine-gitlab mailing list -- wine-gitlab@winehq.org To unsubscribe send an email to wine-gitlab-leave@winehq.org