Making it easier to work with shaders https://git.yummers.dev/slang.git/atom?h=master 2024-01-24T00:57:44+00:00 2024-01-24T00:57:44+00:00 Jay Kwak 82421531+jkwak-work@users.noreply.github.com 2024-01-24T00:57:44+00:00 urn:sha1:4d217907665180537ea217f9f2213c9d53a22b99 * Fix incorrect behavior of operator% Fixes #1059. This change fixes the incorrect translation of "operator%" from HLSL to SPIRV. The issue stems from the fact that the behavior of "operator%" in GLSL differs from that in HLSL. In HLSL it behaves as "remainder" where as it behaves as "modulus" in GLSL. We have been using SpvOpFMod for operator% when Slang compiles from HLSL to SPRIV, which is incorrect. This change switches it to SpvOpFRem. The tests are slightly modified to reveal any potential issues. * Change output type of test/compute/frem For testing the operator%, we are using "int" as the output type of the test, "test/compute/frem.slang". Since the operands are in float type, it is more preferable to have a float type as the resulting type. This can be done with an option, "-output-using-type". --------- Co-authored-by: Yong He <yonghe@outlook.com> 2019-09-18T20:20:22+00:00 Tim Foley tfoleyNV@users.noreply.github.com 2019-09-18T20:20:22+00:00 urn:sha1:a431d4f6da9e463c349c2e3819e87a83c8f2e043 Work on #1059 The `%` operator in the Slang implementation had several issues, and this change tries to address some of them: * Renamed most occurences of "mod" describing this operator to be "rem" for "remainder" to better match its semantics in HLSL * Split the operator into distinct integer and floating-point variants (`IRem` and `FRem`) to simplify having different codegen for the two * Added floating-point variants of `operator%` and `operator%=` to the stdlib. * Added custom C++ codegen for `kIROp_FRem` such that it maps to the standard C/C++ `remainder()` function * Added custom GLSL codegen so that `kIROp_FRem` maps to the GLSL `mod()` function (which isn't correct...) * Added a test case to confirm that D3D11, D3D12, and CPU targets all agree on the definition of floating-point `%` * Fixed `render-test-tool` to allow a negative integer in a `data=...` specification. This didn't end up being used in the final test, but still seems like a good fix. * Added a customized baseline for the Vulkan flavor of that test to confirm that we are *not* compiling correctly to SPIR-V just yet Addressing the correctness of the output for GLSL/SPIR-V will have to come as a later change given that the operation we want is not exposed directly by unextended GLSL.