Skip to content
Snippets Groups Projects

vkd3d-shader/ir: Emit a shader error if the control point phase id cannot be inserted.

Closed Conor McCarthy requested to merge cmccarthy/vkd3d:normaliser_messages into master
1 unresolved thread

A message context in the normaliser will also be needed for the next normalisation patch set.

Merge request reports

Approval is optional

Closed by Conor McCarthyConor McCarthy 1 year ago (Apr 26, 2023 5:43am UTC)

Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
18 18
19 19 #include "vkd3d_shader_private.h"
20 20
21 static void VKD3D_PRINTF_FUNC(3, 4) shader_normaliser_error(struct vkd3d_shader_normaliser *normaliser,
22 enum vkd3d_shader_error error, const char *format, ...)
23 {
24 va_list args;
25
26 va_start(args, format);
27 vkd3d_shader_verror(normaliser->message_context, &normaliser->location, error, format, args);
28 va_end(args);
29 normaliser->failed = true;
  • Conor McCarthy added 1 commit

    added 1 commit

    • 4d0b7ca6 - vkd3d-shader/ir: Emit a shader error if the control point phase id cannot be inserted.

    Compare with previous version

  • I don't think it really makes sense to track the location in the vkd3d_shader_normaliser structure. After a couple of transformations, the instruction index may no longer have much of a relation to the original source location. I think we should instead store location information in the vkd3d_shader_instruction structure, much like how the HLSL compiler stores location information in e.g. the hlsl_ir_node structure. Eventually, that should also make it straightforward to emit SpvOpLine instructions in the SPIR-V backend, giving us useful debug information in the generated SPIR-V.

    I'm not quite sure about VKD3D_SHADER_ERROR_IR_REGISTER_ORDER_TOO_HIGH. On the one hand, it makes sense that we'd have our own errors on the IR level. On the other hand, this feels like something the TPF frontend should have caught and emitted an error for while parsing. Perhaps others have opinions?

  • I'm not quite sure about VKD3D_SHADER_ERROR_IR_REGISTER_ORDER_TOO_HIGH. On the one hand, it makes sense that we'd have our own errors on the IR level. On the other hand, this feels like something the TPF frontend should have caught and emitted an error for while parsing. Perhaps others have opinions?

    That does sound like something the DXBC frontend should validate rather than the normalizer.

  • closed

  • Please register or sign in to reply
    Loading