Making it easier to work with shaders https://git.yummers.dev/slang.git/atom?h=master 2024-10-29T06:49:26+00:00 2024-10-29T06:49:26+00:00 Ellie Hermaszewska ellieh@nvidia.com 2024-10-29T06:49:26+00:00 urn:sha1:f65d756bff8d4c5cbc15bd0322a2ae8e6b896a21 * format * Minor test fixes * enable checking cpp format in ci 2024-07-17T17:53:19+00:00 kaizhangNV 149626564+kaizhangNV@users.noreply.github.com 2024-07-17T17:53:19+00:00 urn:sha1:2db15080085856ed9b5f20642dbb354aac59a888 * Move the file public header files to `include` dir Close the issue (#4635). Move the following headers files to a `include` dir located at root dir of slang repo: slang-com-helper.h -> include/slang-com-helper.h slang-com-ptr.h -> include/slang-com-ptr.h slang-gfx.h -> include/slang-gfx.h slang.h -> include/slang.h Change cmake/SlangTarget.cmake to add include path to every target, and change the source file to use "#include <slang.h>" to include the public headers. The source code update is by the script like follow: ``` fileNames_slang=$(grep -r "\".*slang\.h\"" source/ -l) for fileName in "${fileNames_slang[@]}" do echo "$fileName" sed -i "s/\".*slang\.h\"/\"slang\.h\"/" $fileName done ``` * Fix the test issues * Fix cpu test issues by adding include seach path * Update cmake to not add include path for every target Also change "#include <slang.h>" to "include "slang.h" " to make the coding style consistent with other slang code. * Change public include to private include for unit-test and slang-glslang 2020-02-04T01:36:32+00:00 Tim Foley tfoleyNV@users.noreply.github.com 2020-02-04T01:36:32+00:00 urn:sha1:b415760d7f166eaad7fa27daa09edc9a8964c37e * Initial steps on GPU printing example This change is checkpointing work on a new Slang example that shows how a "GPU `printf()`" can be implemented almost entirely in user space thanks to a combination of Slang language and API features. The example is not perfect as it stands today due to limitations in our current handling of hashed string literals: * At call sites where a string literal is passed, we currently have to explicitly invoke `getStringHash()` to get the hash code, because we don't currently support `String` as a function argument/parameter type. * On the implementation side, because strings are passed as their `int` hash codes, we can't tell them apart from ordinary `int` arguments. The current code handles this by assuming an `int` is *always* a hashed string, which obviously isn't appropriate. There are plenty of other limitations in the implementation presented, but the above are the two main things I'd like to address in follow-up work. I would like to checkpoint this work on the application first, in order to keep work on the Slang implementation and the example as separate as possible. * typo