| Commit message (Collapse) | Author | Age | |
|---|---|---|---|
| * | Fix incorrect behavior of operator% (#3470) | Jay Kwak | 2024-01-23 |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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> | ||
| * | Clean up some behavior of operator% (#1060) | Tim Foley | 2019-09-18 |
| 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. | |||
 |
index : slang.git | |
| Making it easier to work with shaders |
| summaryrefslogtreecommitdiffstats |