Making it easier to work with shaders https://git.yummers.dev/slang.git/atom?h=master 2017-08-07T22:16:54+00:00 2017-08-07T22:16:54+00:00 Tim Foley tfoley@nvidia.com 2017-08-07T21:54:55+00:00 urn:sha1:7b54f43fb1b123f451460edb0add218a0428fe95 There were two main places where global variables were used in the Slang implementation: 1. The "standard library" code was generated as a string at run-time, and stored in a global variable so that it could be amortized across compiles. 2. The representation of types uses some globals (well, class `static` members) to store common types (e.g., `void`) and to deal with memory lifetime for things like canonicalized types. In each case the "simple" fix is to move the relevant state into the `Session` type that controlled their lifetime already (the `Session` destructor was already cleaning up these globals to avoid leaks). For the standard library stuff this really was easy, but for the types it required threading through the `Session` a bit carefully. One more case that I found: there was a function-`static` variable used to generate a unique ID for files output when dumping of intermediates is enabled (this is almost strictly a debugging option). Rather than make this counter per-session (which would lead to different sessions on different threads clobbering the same few files), I went ahead and used an atomic in this case. Note that the remaining case I had been worried about was any function-`static` counter that might be used in generating unique names. It turns out that right now the parser doesn't use such a counter (even in cases where it probably should), and the lowering pass already uses a counter local to the pass (again, whether or not this is a good idea). This change should be a major step toward allowing an application to use Slang in multiple threads, so long as each thread uses a distinct `SlangSession`. The case of using a single session across multiple threads is harder to support, and will require more careful implementation work. 2017-07-09T01:18:36+00:00 Tim Foley tfoley@nvidia.com 2017-07-07T21:30:26+00:00 urn:sha1:f69bc6cdb10aab2d1b202668cb7ecbcc0ddf33f2 This is in anticipation of needing to have more complete knowledge to be able to handle user code that `import`s library functionality. The big picture of this change is just to remove the `UnparsedStmt` class that was used to hold the bodies of user functions as opaque token streams, and thus to let the full parser and compiler loose on that code. That is the easy part, of course, and the hard part is all the fixes that this requires in the rest of the compielr to make this even remotely work. Subsequent commit address a lot of other issues, so this particular commit mostly represents work-in-progress. One detail is that this change puts a conditional around nearly every diagnostic message in `check.cpp` to suppress thing when in rewriter mode. I have yet to check how that works out if there are errors in anything we actually need to understand for the purposes of generating reflection data. 2017-06-15T20:24:25+00:00 Tim Foley tfoley@nvidia.com 2017-06-15T20:24:25+00:00 urn:sha1:205187b561c3b31fa931e73e8f7263f0c4b1de41 Getting rid of more namespace complexity and stripping things down to the basics. This also gets rid of some dead code in the "core" library. 2017-06-15T20:12:51+00:00 Tim Foley tfoley@nvidia.com 2017-06-15T20:12:51+00:00 urn:sha1:517513645afb8eaf4841e7b7035f1ba3a9c7cd57 This gets rid of one unecessary namespace. 2017-06-09T20:44:59+00:00 Tim Foley tfoley@nvidia.com 2017-06-09T18:34:21+00:00 urn:sha1:fcf83dbf9effab3bd98bad2b83b2468b7eb05cfd