Skip to content
Snippets Groups Projects

vkd3d-shader/d3d-asm: Trace VSIR program descriptors.

Merge request reports

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
  • Giovanni Mascellani mentioned in merge request !1447 (merged)

    mentioned in merge request !1447 (merged)

  • +static const char *string_from_register_type(enum vkd3d_shader_register_type type)
    +{
    +    switch (type)
    +    {
    +#define X(x) case VKD3DSPR_ ## x: return #x
    +        X(TEMP);
    ...
    +#undef X
    +        case VKD3DSPR_INVALID:
    +        case VKD3DSPR_COUNT:
    +            break;
    +    }
    +    return "<invalid>";
    +}

    Ideally, I think we'd include this kind of thing in the vsir disassembly, much like e.g. dump_dxbc_signature(). That's not something I'm going to insist on though. In that case I think it would make sense to structure this a bit more like shader_print_interpolation_mode(), and perhaps use shader_register_names[]. (Those names aren't completely unique, but not in a way that matters, I think.) If we're not going to do that, and use string_from_register_type() only for debug output, we might as well use vkd3d_dbg_sprintf() for the unhandled cases.

    string_from_resource_type() is pretty much just a variant of shader_dump_resource_type(), and I don't think we care about the differences here. string_from_resource_data_type() has a lot in common with shader_dump_data_type(), and I'm inclined to suggest introducing vkd3d_data_type_from_resource_data_type() and then just using shader_dump_data_type(). There's an alternative argument that we should be using enum vkd3d_data_type in struct vkd3d_shader_descriptor_info1 to begin with, since it's an internal structure despite the name, and we're converting from enum vkd3d_data_type to enum vkd3d_shader_resource_data_type in vkd3d_shader_scan_typed_resource_declaration(). We could then do that conversion in convert_descriptor_info() instead.

  • Ideally, I think we'd include this kind of thing in the vsir disassembly, much like e.g. dump_dxbc_signature(). That's not something I'm going to insist on though. In that case I think it would make sense to structure this a bit more like shader_print_interpolation_mode(), and perhaps use shader_register_names[]. (Those names aren't completely unique, but not in a way that matters, I think.) If we're not going to do that, and use string_from_register_type() only for debug output, we might as well use vkd3d_dbg_sprintf() for the unhandled cases.

    I agree that we should eventually have a D3D-ASM extension to describe resources as we do for signatures, but to me the internal representation of a VSIR shader shouldn't be conflated with public-facing formats. I know VSIR was born essentially as a spin-off of the Microsoft shader formats, but I don't think that's an especially good format for an IR and I don't think we should keep it tied to its origin.

    Relatedly, I find the names in shader_register_names[] a rather poor choice, in many cases they don't really help understanding what it's being talked about. They might make sense when outputting DXBC metadata, because that's a case that's already by definition related to Microsoft shader formats, but as I said I don't think that should be an argument here.

    It's instead fine to add a number to the unhandled cases.

    string_from_resource_type() is pretty much just a variant of shader_dump_resource_type(), and I don't think we care about the differences here. string_from_resource_data_type() has a lot in common with shader_dump_data_type(), and I'm inclined to suggest introducing vkd3d_data_type_from_resource_data_type() and then just using shader_dump_data_type(). There's an alternative argument that we should be using enum vkd3d_data_type in struct vkd3d_shader_descriptor_info1 to begin with, since it's an internal structure despite the name, and we're converting from enum vkd3d_data_type to enum vkd3d_shader_resource_data_type in vkd3d_shader_scan_typed_resource_declaration(). We could then do that conversion in convert_descriptor_info() instead.

    I like having lowercase field names and uppercase enumerants because I find it easier to segment the text, but I can pass on that. I'll work on integrating your suggestions.

  • Ideally, I think we'd include this kind of thing in the vsir disassembly, much like e.g. dump_dxbc_signature(). That's not something I'm going to insist on though. In that case I think it would make sense to structure this a bit more like shader_print_interpolation_mode(), and perhaps use shader_register_names[]. (Those names aren't completely unique, but not in a way that matters, I think.) If we're not going to do that, and use string_from_register_type() only for debug output, we might as well use vkd3d_dbg_sprintf() for the unhandled cases.

    I agree that we should eventually have a D3D-ASM extension to describe resources as we do for signatures, but to me the internal representation of a VSIR shader shouldn't be conflated with public-facing formats. I know VSIR was born essentially as a spin-off of the Microsoft shader formats, but I don't think that's an especially good format for an IR and I don't think we should keep it tied to its origin.

    This wouldn't be public though, just in our internal disassembly, much like e.g. VSIR_ASM_FLAG_DUMP_TYPES. That also means the format wouldn't need to be stable.

  • added 7 commits

    • b73540ab - vkd3d-shader: Represent resource data types in vkd3d_data_type in descriptors.
    • d88be82b - vkd3d-shader/d3d-asm: Pass a string buffer to shader_dump_resource_type().
    • f9f12d19 - vkd3d-shader/d3d-asm: Expose the raw value if unknown in shader_dump_resource_type().
    • abea3cf5 - vkd3d-shader/d3d-asm: Pass a string buffer to shader_dump_data_type().
    • 0d09eb1c - vkd3d-shader/d3d-asm: Expose the raw value if unknown in shader_dump_data_type().
    • 3628410a - vkd3d-shader/d3d-asm: Trace the register name for I/O declarations.
    • a7b8e3db - vkd3d-shader/d3d-asm: Trace VSIR program descriptors.

    Compare with previous version

  • Hopefully it's a bit better now.

  • Giovanni Mascellani mentioned in merge request !1448 (merged)

    mentioned in merge request !1448 (merged)

  • Henri Verbeet approved this merge request

    approved this merge request

  • Henri Verbeet added 69 commits

    added 69 commits

    • a7b8e3db...4412a836 - 63 commits from branch wine:master
    • 24e61cf7 - vkd3d-shader: Represent resource data types as vkd3d_data_type in struct...
    • f4e10ea9 - vkd3d-shader/d3d-asm: Include the I/O signatures when tracing vsir code.
    • fd16bba2 - vkd3d-shader/d3d-asm: Expose the raw value if unknown in shader_dump_resource_type().
    • bac69493 - vkd3d-shader/d3d-asm: Expose the raw value if unknown in shader_dump_data_type().
    • 0417f4f1 - vkd3d-shader/d3d-asm: Include the program descriptors when tracing vsir code.
    • f02ea94c - vkd3d-shader/d3d-asm: Trace register names for I/O declarations.

    Compare with previous version

Please register or sign in to reply
Loading