Skip to content
Snippets Groups Projects

vkd3d-shader: Maintenance patches

Merged Conor McCarthy requested to merge cmccarthy/vkd3d:shader_maintenance into master
2 unresolved threads

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
775 775 VKD3D_SIV_LINE_DENSITY_TESS_FACTOR = 22,
776 776 };
777 777
778 struct sm6_signature_element
779 {
780 const char *semantic_name;
781 unsigned int semantic_index;
782 unsigned int stream_index;
783 enum vkd3d_shader_sysval_semantic sysval_semantic;
784 enum vkd3d_shader_component_type component_type;
785 unsigned int register_index;
786 unsigned int register_count;
787 unsigned int mask;
788 unsigned int used_mask;
789 enum vkd3d_shader_minimum_precision min_precision;
790 };
  • Comment on lines +778 to +790

    Is it really sensible to call this sm6_signature_element? AFAIU it is not specific for SM6, it is used for all shader models. Maybe internal_signature_element would be a more neutral name?

    Relatedly, why isn't the new field exposed to the public API? Just because we don't want to go through the hassle of updating the public API, or is it genuinely uninteresting for our clients?

  • Please register or sign in to reply
  • Giovanni Mascellani
    Giovanni Mascellani @giomasce started a thread on commit 8b25e7c5
  • 36303 36303 ID3D12Resource_Unmap(buffer, 0, NULL);
    36304 36304
    36305 36305 ID3D12Resource_Release(buffer);
    36306 }
    36307
    36308 static void test_vs_ps_relative_addressing(void)
  • Is it really sensible to call this sm6_signature_element? AFAIU it is not specific for SM6, it is used for all shader models. Maybe internal_signature_element would be a more neutral name?

    True. We wouldn't need the "internal_" prefix either though, because the public version is called "vkd3d_shader_signature_element".

    Relatedly, why isn't the new field exposed to the public API? Just because we don't want to go through the hassle of updating the public API, or is it genuinely uninteresting for our clients?

    Mostly some variant of the former; that doesn't prevent us from exposing this at some point in the future, of course. I think we'd want to wait with exposing this in the public API until broader DXIL support is settled a bit, in case there are additional API changes we'd like to make.

    Is there a reason why this couldn't be a .shader_test, beside missing HLSL compiler support?

    I don't think so, no; see also !181 (comment 31337)

  • Conor McCarthy added 2 commits

    added 2 commits

    • 8c070462 - vkd3d-shader: Introduce an internal shader signature structure.
    • 9bdb55ca - tests/d3d12: Test register relative addressing in vertex and pixel shaders.

    Compare with previous version

  • Alexandre Julliard added 44 commits

    added 44 commits

    • 9bdb55ca...34ddc133 - 40 commits from branch wine:master
    • 85eb2314 - vkd3d-shader/d3dbc: Return an error from vkd3d_shader_sm1_parser_create() if the parser failed.
    • 5ae06816 - vkd3d-shader/tpf: Return an error from vkd3d_shader_sm4_parser_create() if the parser failed.
    • a0a18b16 - vkd3d-shader: Introduce an internal shader signature structure.
    • 7917a682 - tests/d3d12: Test register relative addressing in vertex and pixel shaders.

    Compare with previous version

  • Alexandre Julliard approved this merge request

    approved this merge request

  • Please register or sign in to reply
    Loading