Skip to content
Snippets Groups Projects

vkd3d-shader/hlsl: Support frac() intrinsic.

Merged Nikolay Sivov requested to merge nsivov/vkd3d:hlsl_frac into master
1 unresolved thread

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
  • Should we have some tests to go along with this? For example, what is the expected value of "frac(-2.25)"? GLSL defines "fract(x)" as equivalent to "x - floor(x)"; I'm not sure that necessarily matches HLSL/D3D, and this seems a nice occasion to find out.

  • Author Developer

    As far as I can tell, it's translated unconditionally to 'frc' instruction for both sm4 and older. For this specific constant, it does match "x - floor(x)", giving 0.75, with floor begin -3.0. But such optimization on constant input should be done somewhere else, or do you mean we should have a test now anyway?

    • As far as I can tell, it's translated unconditionally to 'frc' instruction for both sm4 and older. For this specific constant, it does match "x - floor(x)", giving 0.75, with floor begin -3.0. But such optimization on constant input should be done somewhere else, or do you mean we should have a test now anyway?

      Right, translating this to "frc" makes sense. We're also implicitly testing the GLSL and SPIR-V backends with .shader_test tests though, and I don't think we have existing coverage for frc/frac() there.

      Optimising constant inputs would happen in hlsl_fold_constant_exprs(). I think handling HLSL_OP1_FRACT should be fairly straightforward, but I don't think it's a requirement for this MR.

      I do think that as a matter of principle having test coverage for the different intrinsics we implement is simply a good idea. These tests don't necessarily need to be complicated; see e.g. "sqrt.shader_test" for a straightforward example.

    • I do think that as a matter of principle having test coverage for the different intrinsics we implement is simply a good idea. These tests don't necessarily need to be complicated; see e.g. "sqrt.shader_test" for a straightforward example.

      For the record, at some point I duplicated some tests so that both the constant folding path and the real codegen path would be tested. See for example arithmetic-float.shader_test vs arithmetic-float-uniform.shader_test. It wouldn't probably be a bad idea to make that more systematic, but I agree that's not a requirement for this MR. Just saying.

    • Please register or sign in to reply
  • Nikolay Sivov added 1 commit

    added 1 commit

    • abb580c0 - vkd3d-shader/hlsl: Support frac() intrinsic.

    Compare with previous version

  • Author Developer

    Pushed a minimal test.

  • Elizabeth Figura approved this merge request

    approved this merge request

  • Nikolay Sivov added 22 commits

    added 22 commits

    Compare with previous version

  • Henri Verbeet approved this merge request

    approved this merge request

  • Giovanni Mascellani approved this merge request

    approved this merge request

  • added 2 commits

    • 3db50938 - 1 commit from branch wine:master
    • 3e6fccdb - vkd3d-shader/hlsl: Support frac() intrinsic.

    Compare with previous version

  • Alexandre Julliard approved this merge request

    approved this merge request

Please register or sign in to reply
Loading