Skip to content
Snippets Groups Projects

vkd3d-shader/hlsl: Add support for any() intrinsic.

Merged Ethan Lee requested to merge flibitijibibo/vkd3d:hlsl-any into master
1 unresolved thread

For now, this is limited to float and bool, scalar and vector. All other types are unsupported.

Fixes https://bugs.winehq.org/show_bug.cgi?id=54777

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
  • Elizabeth Figura
  • Ethan Lee added 1 commit

    added 1 commit

    • ebd09470 - tests: Add tests for any() intrinsic.

    Compare with previous version

  • Ethan Lee resolved all threads

    resolved all threads

  • Elizabeth Figura approved this merge request

    approved this merge request

  • Giovanni Mascellani
    Giovanni Mascellani @giomasce started a thread on commit ebd09470
  • 48 draw quad
    49 probe all rgba (1.0, 1.0, 1.0, 1.0)
    50
    51 [require]
    52 shader model >= 4.0
    53
    54 [pixel shader]
    55 uniform bool4 b;
    56
    57 float4 main() : sv_target
    58 {
    59 return any(b);
    60 }
    61
    62 [test]
    63 uniform 0 uint4 1 1 1 1
    • This is technically an ABI violation, because true is represented in SM4 as 0xffffffff, not 1. In practice it shouldn't matter, but given that it's not that hard could you change the shader to

      uniform uint4 b;
      
      float4 main() : sv_target
      {
          return any((bool4)b);
      }

      and similar for the scalar case?

    • Author Contributor

      Done!

    • This is technically an ABI violation, because true is represented in SM4 as 0xffffffff, not 1.

      Is that actually the case? True is ~0u internally while in the shader, but do we know that it's required to pass it that way to the shader, or does the shader normalize it? It's hard to find any documentation for this...

    • Sounds like that needs tests (in a separate MR of course).

    • Sounds like that needs tests (in a separate MR of course).

      It seems like native always compares to zero (I can get it to use movc and ine), but I'm not particularly sure how to write a convincing test for this?

    • That's with the uniform declared as bool I guess? I can't think of any better test right now but it does sound like normalization is happening.

    • Yes. I'll see if I can write something for this. If nothing else I suspect it'll prove we're doing something wrong.

    • I tried a few examples:

      bool4 main(int4 x : color) : SV_TARGET
      {
      	return x;
      }

      compiles to

      ps_4_0
      dcl_input_ps constant v0.xyzw
      dcl_output o0.xyzw
      ine o0.xyzw, v0.xyzw, l(0, 0, 0, 0)
      ret 

      (https://shader-playground.timjones.io/63ec9c244edae1d822a1daf5fbc79d40)

      So it seems that the native compiler feels an obligation to generate an actual 0xffffffff for a true, otherwise it could have just moved v0 to o0.

      bool4 main(bool4 x : color) : SV_TARGET
      {
      	return x;
      }

      compiles to

      ps_4_0
      dcl_input_ps constant v0.xyzw
      dcl_output o0.xyzw
      mov o0.xyzw, v0.xyzw
      ret 

      (https://shader-playground.timjones.io/1647c611f02ea54b06828cae9a668fac)

      It seems that the native compiler trusts that a true bool is represented as 0xffffffff, otherwise it couldn't satisfy the obligation it seems to have from the test above.

      int4 main(bool4 x : color) : SV_TARGET
      {
      	return x;
      }

      compiles to

      ps_4_0
      dcl_input_ps constant v0.xyzw
      dcl_output o0.xyzw
      and o0.xyzw, v0.xyzw, l(1, 1, 1, 1)
      ret 

      (https://shader-playground.timjones.io/c9b0ea8dd59ebb5bfe44b326816f527c)

      This is possibly the most convincing test: if the compiler didn't have the guarantee that true's are always 0xffffffff this would be miscompiled.

      So it seems that representing true as 0xffffffff is a requirement at the boundary of the shader, in both directions.

    • That's a semantic, though. If you use a uniform instead, the code seems to change, to stop assuming that true is ~0. The same result happens for vs input semantics. This makes sense, given that a ps semantic would have been generated not by the user but by the vs.

    • Ha, you're right, interesting. Then I retire my comment. On the contrary, we should probably make sure that we do the same, at some point. But that's for another MR. Or maybe we already do that?

    • Please register or sign in to reply
  • Ethan Lee added 1 commit

    added 1 commit

    • d987f600 - tests: Add tests for any() intrinsic.

    Compare with previous version

  • Ethan Lee resolved all threads

    resolved all threads

  • Giovanni Mascellani approved this merge request

    approved this merge request

  • This will need a rebase because it conflicts with an earlier MR.

  • Ethan Lee added 16 commits

    added 16 commits

    Compare with previous version

  • Ethan Lee added 2 commits

    added 2 commits

    • e84908fe - vkd3d-shader/hlsl: Add support for any() intrinsic.
    • 479bd715 - tests: Add tests for any() intrinsic.

    Compare with previous version

  • Henri Verbeet approved this merge request

    approved this merge request

  • Alexandre Julliard approved this merge request

    approved this merge request

  • Please register or sign in to reply
    Loading