summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2019-07-29Fix issue with outputting "static" in GLSL (#1006)Tim Foley
This appears to be a regression introduced in #1001, and missed because none of our existing tests covered `static const` arrays on the GLSL/SPIR-V targets. The basic problem is that we cannot output a `static const` definition in GLSL because `static` is a reserved word and not a keyword. Instead for GLSL we just want a `const` array. This change makes the emission of `static` for global-scope constants key on the target language for code generation, and only emit it for HLSL, C, and C++. This change also adds a test case specifically for running Slang input that has a `static const` array on the Vulkan target.
2019-07-29Add an attribute to disable the overlapping-bindings warning (#1005)Tim Foley
Currently if the user gives two global shader parameters conflicting bindings, they get a warning diagnostic: ```hlsl Texture2D a : register(t0); Texture2D b : register(t0); // WARNING: overlapping bindings ``` This change adds a way to locally disable that warning using an attribute: ```hlsl [allow("overlapping-bindings")] Texture2D a : register(t0); [allow("overlapping-bindings")] Texture2D b : register(t0); // OK ``` Note that as a policy decision, the implementation requires `[allow("overlapping-bindings")]` on both declarations in order to disable the warning, under the assumption that the behavior should be strictly opt-in, and not silently affect a programmer who adds a new shader parameter with no knowledge or expectation of possible overlap. The `[allow(...)]` attribute is intended to be a fairly generally mechanism for disabling optional diagnostics within certain scopes (e.g., for the body of a function definition), but as implemented in this change it is quite restrictive: * Only the single name `"overlapping-bindings"` will be recognized, and this name cannot be used with, e.g., a `-W` flag on the command line to enable/disable the same diagnostic, or turn it into an error. Adding more cases would be easy enough, but wiring it up to command-line flags could be trickier. * Only the code that checks for parameter binding overlap is currently checking for `[allow(...)]` attributes, so it is not "wired up" to enable/disable any others. Doing this systematically would ideally involve something in `diagnose()`, but there could be complications to a systematic approach (finding the AST node(s) to use when searching for `[allow(...)]`. On gotcha here is that versions of Slang without this feature will error out on the `[allow(...)]` attribute since they don't understand it, and if we add future diagnostics that it covers then old compiler versions will (as written) error out on a diagnostic they haven't heard of rather than just assume the `[allow(...)]` attribute doesn't apply to them. These kinds of issues can and should be addressed in future changes.
2019-07-22Use C++ template types in code generation (#1000)jsmall-nvidia
* WIP: Adding support for C/C++ compilation to slang API. * Removed BackEndType in test harness -> use SlangPassThrough to identify backends Only require stage for targets that require it. Detection of all different backends. * Windows/Unix create temporary filename. * WIP: Output CPU binaries. * Added a pass-through c/c++ test. * Compile C++/C and store in temporary file. * Read the binary back into memory. * Set debug info and optimization flags for C/C++. Make the CPPCompiler debug/optimization levels match slangs. * Handling of include paths and math precision. * Dumping c++/c source and exe/shared library. * Put hex dump into own util. * End to end pass through c compilation test. * WIP: Simple execute test working on Linux/Unix. * Fix typo on linux. * WIP: To compile slang to cpp shared library. Report backend compiler errors. * Compiles slang -> cpp and loads as shared library. * Fix problem on c-cross-compile test because prelude is now included with <> quotes. * Run slang generated cpp code - using hard coded data. * Added cpp-execute-simple, and test output. * Fix warning that broke win32 build. * Fix compilation problem on osx. * When C++ output use template types. * Require C++14 if using partial specialization for matrix/vector types. * Merge of master + add c-cross-compile.slang.expected * Remove c-cross-compile.slang.expected
2019-07-18Add back a notion of IR global constants (#1002)Tim Foley
This change adds back a little bit of explicit support for global constants in the IR, after a previous change completely removed the existing `IRGlobalConstant` node type. The new `IRGlobalConstant` is *not* a parent instruction, and doesn't function at all like the old one. Instead it is effectively a simple instruction that takes zero or one operands: * The zero-operand case represents a constant with unknown value. This would usually come from another module, and thus would have an `[import(...)]` linkage decoration, so that after linking it resolves to a constant with a known value. * In the one-operand case, the single operand represents the value of the constant, so that the operation semantically behaves like an identity function. It exists just to give decorations something to "attach" to, so that a global constant with a value can have, e.g., an `[export(...)]` decoration to establish linkage. The IR lowering pass was updated to create the new node type to wrap any global constants. For now we do this both for global `static const` variables and function-scope `static const`, although the latter doesn't really need the extra indirection. The IR linking logic was extended to handle linking of global constants akin to how other global instructions are handled. The new logic is mostly boilerplate, and it is likely that a refactor of the linking logic would eliminate the need for this kind of per-instruction-opcode handling of IR instructions that can have linkage. A custom pass was added that is intended to be run right after linking (it could arguably be folded into `linkIR()`, but I thought it was safer to keep each pass as small as possible). This pass replaces any `IRGlobalConstant` that has a value (operand) with that value, so that global constants should be eliminated after the linking step. This ensures that downstream optimization/transformation passes don't have to deal with the possibility of global constants. Almost all the existing passes would Just Work if global constants were left in the IR. The two big exceptions are: * Anything that relies on testing `IRInst*` identity as a way to test for things having the same value would break, since a global constant is a distinct `IRInst*` from its value. * The type legalization pass doesn't handle `IRGlobalConstant` instructions with non-simple types. This could be added if we ever wanted it, but it seemed silly to write this code now if it would always be dead (and thus untested). I went ahead and updated the emit logic to handle an `IRGlobalConstant`s that still existing in the IR module at emit time, since the amount of code required was small so that being robust to that case seemed safest (e.g., in case we ever want to have a path that emits code directly while skipping some/all of our IR transformation passes). There should be no visible changes to the functionality of the compiler with this change, but it should help make IR dumps from the front-end more clear/explicit (since each constant will be a distinct instruction with its own name), and paves the way for supporting proper cross-module linkage of constants.
2019-07-17Change how global-scope constants are handled (#1001)Tim Foley
Before this change, global and function-scope `static const` declarations were represented as instructions of type `IRGlobalConstant`, which was represented similarly to an `IRGlobalVar`: with a "body" block of instructions that compute/return the initial value. This representation inhibited optimizations (because a reference to a global constant would not in general be replaced with a reference to its value), and also caused problems for resource type legalization because the logic for type legalization did not (and still does not) handle initializers on globals (so global *variables* that contain resource types are still unsupported). The change here is simple at the high level: we get rid of `IRGlobalConstant` and instead handle global-scope constants as "ordinary" instructions at the global scope. E.g., if we have a declaration like: static const int a[] = { ... } that will be represented in the IR as a `makeArray` instruction at the global scope, referencing other global-scope instructions that represent the values in the array. This simple choice addresses both of the main limitations. A `static const` variable of integer/float/whatever type is now represented as just a reference to the given IR value and thus enables all the same optimizations. When a `static const` variable uses a type with resources, the existing legalization logic (which can handle most of the "ordinary" instructions already) applies. Another secondary benefit of this approach is that the hacky `IREmitMode` enumeration is no longer needed to help us special-case source code emit for `static const` variables. Beyond just removing `IRGlobalConstant`, and updating the lowering logic to use the initializer direclty, the main change here is to the emit logic to make it properly handle "ordinary" instructions that might appear at global scope. One open issue with this change, that could be addressed in a follow-up change, is that "extern" global constants that need to be imported from another module (but which might not have a known value when the current module is compiled) aren't supported - we don't have a way to put a linkage decoration on them. A future change might re-introduce global constants as a distinct IR instruction type that just references the value as an operand (if it is available). We would then need to replace references to an IR constant with references to its value right after linking.
2019-07-17Slang -> C++ -> SharedLibrary -> Test (#999)jsmall-nvidia
* WIP: Adding support for C/C++ compilation to slang API. * Removed BackEndType in test harness -> use SlangPassThrough to identify backends Only require stage for targets that require it. Detection of all different backends. * Windows/Unix create temporary filename. * WIP: Output CPU binaries. * Added a pass-through c/c++ test. * Compile C++/C and store in temporary file. * Read the binary back into memory. * Set debug info and optimization flags for C/C++. Make the CPPCompiler debug/optimization levels match slangs. * Handling of include paths and math precision. * Dumping c++/c source and exe/shared library. * Put hex dump into own util. * End to end pass through c compilation test. * WIP: Simple execute test working on Linux/Unix. * Fix typo on linux. * WIP: To compile slang to cpp shared library. Report backend compiler errors. * Compiles slang -> cpp and loads as shared library. * Fix problem on c-cross-compile test because prelude is now included with <> quotes. * Run slang generated cpp code - using hard coded data. * Added cpp-execute-simple, and test output. * Fix warning that broke win32 build. * Fix compilation problem on osx.
2019-07-09WIP: slang to C++ code generation (#997)jsmall-nvidia
* WIP: Emitting Cpp * Added HLSLType instead of using IRInst - because they don't seem to be deduped. * Removed need for lexer to take a String. Added mechansim to lookup intrinsic functions on C++. * A c/c++ cross compilation test. * WIP Cpp output using cloning and slang types. * More work to generate mul funcs. * WIP: Outputting some simple C++. * Expose findOrEmitHoistableInst to IRBuilder to aid cloning, * Simplification for checking for BasicTypes. Test infrastructure compiles output C++ code. * Dot and mat/vec multiplication output. * First pass at swizzling. * First support for binary ops. * Builtin binary and unary functions. * Any and all. * WIP adding support for other functions. Added code to generate function signature. * Add scalar functions to slang-cpp-prelude.h * Support for most built in operations. * Tested first ternary. * Checking the emitting of corner cases functions - normalize, length, any, all, normalize, reflect. * Check asfloat etc work. * Fmod support. * WIP Array handling in C++. * First stage in being able to handl arbitrary type output for CLikeSourceEmitter * Removed Handler/Emitter split - so can implement more easily complex type naming. * Array passing by value first pass. * Rename Array -> FixedArray * Outputs structs in C++. * Emit the thread config. * Dimension -> TypeDimension * SpecializedOperation -> SpecializedIntrinsic Operation -> IntrinsicOp Use shared impl of isNominalOp Commented use of m_uniqueModule etc. * Add code to test slang->cpp when compiled doesn't have errors. Does so by building shared library and exporting the entry point. * Fix linux clang/gcc compile error about override not being specified. * Make sure c-cross-compile is run on linux targets/smoke. * Remove c-cross-compile.slang from smoke. * Fix running tests/cross-compile/c-cross-compile.slang on Ubuntu 16.04 * Only add -std=c++11 for C++ source.
2019-07-03Fix declaration of scalar sincos() function. (#996)Tim Foley
The function was accidentally defined with a generic `int` parameter copy-pasted from the vector definition, but that made the scalar version impossible to call with inferred generic arguments, because there wasn't a way to infer `N` when it isn't used in the parameter list. Includes a simple test case to confirm that the front-end no longer chokes on calls to scalar `sincos()`.
2019-06-21Parsing CPP Compiler output (#994)jsmall-nvidia
* Added extractLine line parsing to StringUtil. Use for matching lines instead of calcLines. calcLines uses extractLine to extract lines. Fixed problems found in output of some tests- due to how a how final line is handled. Now a final line has a \r or \n\r combination, but nothing else after it, it is considered the last line (not the line after it). * Use StringUtil::extractLine in slang-generate. * Improved comment on extractLine * Remove test code from StringUtil::extractLine * Made StringUtil::extractLine act as if line terminators are 'separators'. Added unit-test-string.cpp - to check behavior. * Adding LineParser - not entirely necessary, but slightly easier to use. * Hack to output start of tests. * WIP parsing CPPCompiler output. * Make extractLine return a bool. * First attempt at Visual Studio output parsing. * Add handling for checking error returning from CPPCompiler. * First pass parsing output of Gcc/Clang. * Split out VisualStudioCompilerUtil and GCCCompilerUtil. Simplified parsing of versions. * Simplify CPPCompiler::Output interface. * Fix problem with cpp-compiler on linux targets. * Add shared library link error. * Improving GCC/Clang parsing output. * Make cpp compiler parsing function able to return a SlangResult. * Handling for 'info' on clang * Add expected result for c-compile-shared-library-error.c * * Add flags such that link errors on shared libraries are supported. * Added StringUtil::join * Turn off the link shared library unfound symbol option on MacOS because it causes an error (and it's not needed on that target). * Add natvis inclusion back to visual studio projects. * Display message to try and determine crash problem on travisbuild. * Fix bug in handling continuations for clang. Disabled output of exception text. * WIP: See what clang is outputting that is parsing incorrectly on travis. * More handling for travis clang parsing issue. * Restore natvis to core.vcxproj * Fix visual studio project such that it still as natvis.
2019-06-20Hot fix: Remove getExecutablePath reported memory leak (#993)jsmall-nvidia
* Remove the memory leak that is being reported on Visual Stuio, due to getExecutablePath having a static local variable that is not freed before leaks are dumped. The solution is sort of clumsy, in so far as it just removes the cache. Would be nice to have a better way to handle such situations. * Add to do comment - and also to push CI to rebuild.
2019-06-19Feature/shared library review (#992)jsmall-nvidia
* Added setNull to RefPtr Renamed combineBuilder into combineIntoBuilder * Added Path::append
2019-06-19Make extractLine return a bool. (#991)jsmall-nvidia
2019-06-19Start exposing a new COM-lite API (#987)Tim Foley
* Start exposing a new COM-lite API This change is mostly about exposing a new API to the Slang compiler that allows more fine-grained control over the compilation flow. The basic concepts in the new API are: * An `IGlobalSession` is the granularity at which we load/parse the Slang stdlib, and therefore gives applications a way to amortize startup cost for the library across multiple compiles. This is a concept that might be able to go away in a future version of Slang. * An `ISession` owns all the code that gets loaded/compiled/generated. Any `import`ed modules are shared across everything in a session (we don't re-parse/-check the code when we see another `import` for the same module). Any generic- or interface-based code in the session can be specialized using types from the same session (but not necessarily across sessions). * An `IModule` is the unit of code loading and scoping. It doesn't expose any API in this change, but would be the right scope for looking up types or entry points by name. * An `IProgram` is a "linked" combination of modules and entry points from which code can be generated and reflection information queried. This change re-uses the existing reflection API types, rather than introduce a new API that duplicates that functionality. That will probably change in a future revision. There are two major pieces of functionality added here that aren't related to the new API: * We now have an API concept of "entry point groups" which are one or more entry points that are intended to be used together so that they need to have non-overlapping parameters. For now this is being used to handle "hit groups" and local root signatures for ray tracing, but I'm not sure this is a concept we will keep in the long run. * We have a very special-case (client-application-specific) flag that ascribes special meaning to the `shared` keyword, so that it can be attached to global parameters to indicate that they are actually to be part of the local root signature rather than the global one for DXR. None of the API design (including naming) here is finalized; the only reason to check in the changes at this point to avoid having a long-running branch that leads to merge pain. Clients should *not* try to depend on the new API just yet, since it is still a work in progress. * fixup: clang warning * fixup: try to detect clang C++11 support * fixup * fixup * fixup * fixup * fixup: review feedback
2019-06-18StringUtil::extractLine (#989)jsmall-nvidia
* Added extractLine line parsing to StringUtil. Use for matching lines instead of calcLines. calcLines uses extractLine to extract lines. Fixed problems found in output of some tests- due to how a how final line is handled. Now a final line has a \r or \n\r combination, but nothing else after it, it is considered the last line (not the line after it). * Use StringUtil::extractLine in slang-generate. * Improved comment on extractLine * Remove test code from StringUtil::extractLine * Made StringUtil::extractLine act as if line terminators are 'separators'. Added unit-test-string.cpp - to check behavior. * Adding LineParser - not entirely necessary, but slightly easier to use. * Improved LineParser::Iterator end testing. Added improved tests for LineParser. * Move line comparson after termination case - to fix problem with gcc release build. * Make UnownedStringSlice handle comparison when begin is nullptr - as it uses memcmp and passing nullptr to memcmp is undefined, leading to optimizer being able to do some unfortunate optimizations on gcc.
2019-06-18* Added Path::combineBuilder, so as two sub paths can be combined into a ↵jsmall-nvidia
StringBuilder (#988) * Renamed and improved comments on SharedLibrary
2019-06-18Fix bug in handling of `h` literal suffix. (#990)Tim Foley
A literal like: 2.0h is supposed to default to `half` precision, but there was a typo in our logic that meant that the `half` case was mistakenly checking for `l` and not `h` and so it would never trigger (because the `double` case right before it was checking for `l` first), and certainly wouldn't trigger on an `h`. There was also a bug that a literal with `hf`: 2.0hf would go into the path for the `f` suffix without considering the `h`. These changes really ought to have some tests for them, but this was also just a quick issue I noticed while working on something else.
2019-06-17Fix shared library loading for testing. (#986)jsmall-nvidia
* Fix shared library loading for testing. * Improve comments.
2019-06-14Runtime Shared Library compilation and testing (#985)jsmall-nvidia
* Removed the need for VisualStudio specific CPPCompiler Improved the version parsing for gcc/clang Removed need for slang-unix-cpp-compiler-util.cpp/.h Remove binary before compiling in the compile c tests * Moved VisualStudio calcArgs into CPPCompilerUtil - as code is not windows specific. * Set up compile time version for gcc and clang * Fix compilation on OSX - use remove instead of unlink for file deletion. * On OSX - clang uses different string format. * Removed /bin/sh invoking as not required for OSX. * First pass working testing with shared libraries.
2019-06-14CPPCompiler improvements (#984)jsmall-nvidia
* Removed the need for VisualStudio specific CPPCompiler Improved the version parsing for gcc/clang Removed need for slang-unix-cpp-compiler-util.cpp/.h Remove binary before compiling in the compile c tests * Moved VisualStudio calcArgs into CPPCompilerUtil - as code is not windows specific. * Set up compile time version for gcc and clang * Fix compilation on OSX - use remove instead of unlink for file deletion. * On OSX - clang uses different string format. * Removed /bin/sh invoking as not required for OSX.
2019-06-14Abstract CPPCompiler (#983)jsmall-nvidia
* Work in progress to be able to invoke VS from within code. * First pass at windows version of refactor of OSProcessSpawner * Closer to getting VS path lookup working. * Make OSString assignable/ctor able * Work out program files directory directly, so don't have to expand %%. * WIP: Improve handling of process spawning. * Add support for splitting input by line. * * Correctly locates visual studio install * Added functionality to invoke vs via cmd * Add option to execute the command line. * Handle in ProcessUtil for windows -> WinHandle. * Rename files slang-win-visual-studio-util.cpp/.h and slang-process-util.h * First pass at unix/linux version of ProcessUtil. * Fix reading Visual Studio path from the registry. * Get compiling on linux with. * Fix vcvarsall.bat name * Use ProcessUtil to execute external code. * Remove OSProcessSpawner. * Remove includes for "os.h" where no longer needed. * Fix tabbing issue in premake5.lua Remove test code from slang-test-main.cpp * Fix premake4.lua tabbing issue. * Small fixes to slang-process-util.h Init ExecuteResult on Win execute. * Improve comments. * Fix bug in StringUtil::calcLines - with oddly terminated source input being able to read past end. Make slang-generate use StringUtil over it's own impl. * Fix off by one bug in working out Visual Studio version. * Fix bug in calculating Visual Studio Version * Fix compilation on linux with string parameter being passed to messageFormat. * Remove erroneous use of kOSError codes - use Result. * First effort to generate standard compiler options. * Initial efforts in compiling source code in test framework for VisualStudio. * Testing compiling c code on VisualStudio on Windows. * Fix warning on linux. * Fix clang on linux warning (and therefore failing) returning a StringBuilder as String. * Disable return-std-move on clang. * CommandLine arguments are now tagged if they are escaped or not. That it is the clients responsibility to escape command lines that cannot be automatically escaped. * Add checks on unix/linux that command line args are all unescaped. * WIP getting runtime GCC to work. * First pass compiler working on unix-like targets. * Added File::remove function. * Enable c-compile.c test on 'smoke'. * WIP abstracting the CPP compiler concept. * CPPCompilerSet and CPPCompilerUtil working on windows. Problem on unix. * Used stdError for parsing of invoke of compiler to figure out verison. * Removed some code that was no longer needed from slang-cpp-compiler.cpp
2019-06-13Feature/file remove (#982)jsmall-nvidia
* Work in progress to be able to invoke VS from within code. * First pass at windows version of refactor of OSProcessSpawner * Closer to getting VS path lookup working. * Make OSString assignable/ctor able * Work out program files directory directly, so don't have to expand %%. * WIP: Improve handling of process spawning. * Add support for splitting input by line. * * Correctly locates visual studio install * Added functionality to invoke vs via cmd * Add option to execute the command line. * Handle in ProcessUtil for windows -> WinHandle. * Rename files slang-win-visual-studio-util.cpp/.h and slang-process-util.h * First pass at unix/linux version of ProcessUtil. * Fix reading Visual Studio path from the registry. * Get compiling on linux with. * Fix vcvarsall.bat name * Use ProcessUtil to execute external code. * Remove OSProcessSpawner. * Remove includes for "os.h" where no longer needed. * Fix tabbing issue in premake5.lua Remove test code from slang-test-main.cpp * Fix premake4.lua tabbing issue. * Small fixes to slang-process-util.h Init ExecuteResult on Win execute. * Improve comments. * Fix bug in StringUtil::calcLines - with oddly terminated source input being able to read past end. Make slang-generate use StringUtil over it's own impl. * Fix off by one bug in working out Visual Studio version. * Fix bug in calculating Visual Studio Version * Fix compilation on linux with string parameter being passed to messageFormat. * Remove erroneous use of kOSError codes - use Result. * First effort to generate standard compiler options. * Initial efforts in compiling source code in test framework for VisualStudio. * Testing compiling c code on VisualStudio on Windows. * Fix warning on linux. * Fix clang on linux warning (and therefore failing) returning a StringBuilder as String. * Disable return-std-move on clang. * CommandLine arguments are now tagged if they are escaped or not. That it is the clients responsibility to escape command lines that cannot be automatically escaped. * Add checks on unix/linux that command line args are all unescaped. * WIP getting runtime GCC to work. * First pass compiler working on unix-like targets. * Added File::remove function. * Enable c-compile.c test on 'smoke'.
2019-06-13Runtime C++ compiling and testing on Unix-like targets (#981)jsmall-nvidia
* Work in progress to be able to invoke VS from within code. * First pass at windows version of refactor of OSProcessSpawner * Closer to getting VS path lookup working. * Make OSString assignable/ctor able * Work out program files directory directly, so don't have to expand %%. * WIP: Improve handling of process spawning. * Add support for splitting input by line. * * Correctly locates visual studio install * Added functionality to invoke vs via cmd * Add option to execute the command line. * Handle in ProcessUtil for windows -> WinHandle. * Rename files slang-win-visual-studio-util.cpp/.h and slang-process-util.h * First pass at unix/linux version of ProcessUtil. * Fix reading Visual Studio path from the registry. * Get compiling on linux with. * Fix vcvarsall.bat name * Use ProcessUtil to execute external code. * Remove OSProcessSpawner. * Remove includes for "os.h" where no longer needed. * Fix tabbing issue in premake5.lua Remove test code from slang-test-main.cpp * Fix premake4.lua tabbing issue. * Small fixes to slang-process-util.h Init ExecuteResult on Win execute. * Improve comments. * Fix bug in StringUtil::calcLines - with oddly terminated source input being able to read past end. Make slang-generate use StringUtil over it's own impl. * Fix off by one bug in working out Visual Studio version. * Fix bug in calculating Visual Studio Version * Fix compilation on linux with string parameter being passed to messageFormat. * Remove erroneous use of kOSError codes - use Result. * First effort to generate standard compiler options. * Initial efforts in compiling source code in test framework for VisualStudio. * Testing compiling c code on VisualStudio on Windows. * Fix warning on linux. * Fix clang on linux warning (and therefore failing) returning a StringBuilder as String. * Disable return-std-move on clang. * CommandLine arguments are now tagged if they are escaped or not. That it is the clients responsibility to escape command lines that cannot be automatically escaped. * Add checks on unix/linux that command line args are all unescaped. * WIP getting runtime GCC to work. * First pass compiler working on unix-like targets. * Enable c-compile.c test on 'smoke'.
2019-06-12CommandLine arg escaping (#980)jsmall-nvidia
* Work in progress to be able to invoke VS from within code. * First pass at windows version of refactor of OSProcessSpawner * Closer to getting VS path lookup working. * Make OSString assignable/ctor able * Work out program files directory directly, so don't have to expand %%. * WIP: Improve handling of process spawning. * Add support for splitting input by line. * * Correctly locates visual studio install * Added functionality to invoke vs via cmd * Add option to execute the command line. * Handle in ProcessUtil for windows -> WinHandle. * Rename files slang-win-visual-studio-util.cpp/.h and slang-process-util.h * First pass at unix/linux version of ProcessUtil. * Fix reading Visual Studio path from the registry. * Get compiling on linux with. * Fix vcvarsall.bat name * Use ProcessUtil to execute external code. * Remove OSProcessSpawner. * Remove includes for "os.h" where no longer needed. * Fix tabbing issue in premake5.lua Remove test code from slang-test-main.cpp * Fix premake4.lua tabbing issue. * Small fixes to slang-process-util.h Init ExecuteResult on Win execute. * Improve comments. * Fix bug in StringUtil::calcLines - with oddly terminated source input being able to read past end. Make slang-generate use StringUtil over it's own impl. * Fix off by one bug in working out Visual Studio version. * Fix bug in calculating Visual Studio Version * Fix compilation on linux with string parameter being passed to messageFormat. * Remove erroneous use of kOSError codes - use Result. * First effort to generate standard compiler options. * Initial efforts in compiling source code in test framework for VisualStudio. * Testing compiling c code on VisualStudio on Windows. * Fix warning on linux. * Fix clang on linux warning (and therefore failing) returning a StringBuilder as String. * Disable return-std-move on clang. * CommandLine arguments are now tagged if they are escaped or not. That it is the clients responsibility to escape command lines that cannot be automatically escaped. * Add checks on unix/linux that command line args are all unescaped.
2019-06-12Visual Studio compilation working in test harness (#979)jsmall-nvidia
* Work in progress to be able to invoke VS from within code. * First pass at windows version of refactor of OSProcessSpawner * Closer to getting VS path lookup working. * Make OSString assignable/ctor able * Work out program files directory directly, so don't have to expand %%. * WIP: Improve handling of process spawning. * Add support for splitting input by line. * * Correctly locates visual studio install * Added functionality to invoke vs via cmd * Add option to execute the command line. * Handle in ProcessUtil for windows -> WinHandle. * Rename files slang-win-visual-studio-util.cpp/.h and slang-process-util.h * First pass at unix/linux version of ProcessUtil. * Fix reading Visual Studio path from the registry. * Get compiling on linux with. * Fix vcvarsall.bat name * Use ProcessUtil to execute external code. * Remove OSProcessSpawner. * Remove includes for "os.h" where no longer needed. * Fix tabbing issue in premake5.lua Remove test code from slang-test-main.cpp * Fix premake4.lua tabbing issue. * Small fixes to slang-process-util.h Init ExecuteResult on Win execute. * Improve comments. * Fix bug in StringUtil::calcLines - with oddly terminated source input being able to read past end. Make slang-generate use StringUtil over it's own impl. * Fix off by one bug in working out Visual Studio version. * Fix bug in calculating Visual Studio Version * Fix compilation on linux with string parameter being passed to messageFormat. * Remove erroneous use of kOSError codes - use Result. * First effort to generate standard compiler options. * Initial efforts in compiling source code in test framework for VisualStudio. * Testing compiling c code on VisualStudio on Windows. * Fix warning on linux. * Fix clang on linux warning (and therefore failing) returning a StringBuilder as String. * Disable return-std-move on clang.
2019-06-12Runtime execution of Visual Studio Compiler (#978)jsmall-nvidia
* Work in progress to be able to invoke VS from within code. * First pass at windows version of refactor of OSProcessSpawner * Closer to getting VS path lookup working. * Make OSString assignable/ctor able * Work out program files directory directly, so don't have to expand %%. * WIP: Improve handling of process spawning. * Add support for splitting input by line. * * Correctly locates visual studio install * Added functionality to invoke vs via cmd * Add option to execute the command line. * Handle in ProcessUtil for windows -> WinHandle. * Rename files slang-win-visual-studio-util.cpp/.h and slang-process-util.h * First pass at unix/linux version of ProcessUtil. * Fix reading Visual Studio path from the registry. * Get compiling on linux with. * Fix vcvarsall.bat name * Use ProcessUtil to execute external code. * Remove OSProcessSpawner. * Remove includes for "os.h" where no longer needed. * Fix tabbing issue in premake5.lua Remove test code from slang-test-main.cpp * Fix premake4.lua tabbing issue. * Small fixes to slang-process-util.h Init ExecuteResult on Win execute. * Improve comments. * Fix bug in StringUtil::calcLines - with oddly terminated source input being able to read past end. Make slang-generate use StringUtil over it's own impl. * Fix off by one bug in working out Visual Studio version. * Fix bug in calculating Visual Studio Version * Fix compilation on linux with string parameter being passed to messageFormat. * Remove erroneous use of kOSError codes - use Result.
2019-06-06Split out target code generation from CLikeSourceEmitter (#976)jsmall-nvidia
* * Added SourceStyle to CLikeSourceEmitter, to limit cases to actual target types. * Made Impl methods _ prefixed * Small tidyup * * SourceStream -> SourceWriter * use slang-emit- prefix on SourceWriter file * * Remove EmitContext -> merge into CLikeSourceEmitter * slang-c-like-source-emitter -> slang-emit-source.cpp * ExtensionUsageTracker -> GLSLExtensionTracker slang-extension-usage-tracker.cpp/.h -> slang-emit-glsl-extension-tracker.cpp/.h * emit-source.cpp.h -> emit-c-like.cpp/.h * Small fix to move where some _ prefixed functions are declared in CLikeSourceEmitter. * * CLikeSourceEmitter::CInfo -> Desc * Functions to get and find CodeGenTarget by name * Split out empty language impls * Create an impl based on SourceStyle * * CodeGenTarget conversion to and from string * Move HLSL specific functions to HLSLEmitSource. * Emitting texture and image types. * Move move GLSL specific functionality to GLSLSourceEmitter * Split more out of slang-emit-c-like * Refactor more out of slang-emit-c-like * * tryEmitIRInstExprImpl(IRInst* inst, IREmitMode mode, const EmitOpInfo& inOuterPrec) * Fix bug around output of uintBitsToFloat * More work refactoring out target specifics from slang-emit-c-like * Move functions that are only implemented once in GLSL impl into their Impl method. * Move rate qualification out of slang-emit-c-like * * Added getEmitOpForOp - allows for table usage so different ops can be dealt with the same way * Moved vector comparison to slang-emit-glsl * * * Use EmitOpInfo to control output in slang-emit-c-like.cpp for unary ops * Move more functionality from CLikeSourceEmitter to HLSLSourceEmitter * Make output of parameters implementaion specific. * Extracted interpolation modifiers. * Remove IR from methods that don't need them. * Remove IR from method names. * Refactor handling of output of types - to make the impls implement the full path without lots of cases for specific impls * Add variable declaration modifiers and matrix layout to larget specific in slang-emit. * Make target specific internal functions _ prefixed.
2019-06-04Review improvements on #971: WIP: Support for other source target languages ↵jsmall-nvidia
(#974) * * Added SourceStyle to CLikeSourceEmitter, to limit cases to actual target types. * Made Impl methods _ prefixed * Small tidyup * * SourceStream -> SourceWriter * use slang-emit- prefix on SourceWriter file * * Remove EmitContext -> merge into CLikeSourceEmitter * slang-c-like-source-emitter -> slang-emit-source.cpp * ExtensionUsageTracker -> GLSLExtensionTracker slang-extension-usage-tracker.cpp/.h -> slang-emit-glsl-extension-tracker.cpp/.h * emit-source.cpp.h -> emit-c-like.cpp/.h * Small fix to move where some _ prefixed functions are declared in CLikeSourceEmitter.
2019-06-04Update language-guide.md (#975)Kostas Andrianos
Fix logical error on struct MyCoolMaterial in Associated types
2019-05-31Use slang- prefix on slang compiler and core source (#973)jsmall-nvidia
* Prefixing source files in source/slang with slang- * Prefix source in source/slang with slang- prefix. * Rename core source files with slang- prefix. * Update project files. * Fix problems from automatic merge.
2019-05-31WIP: Support for other source target language (#971)jsmall-nvidia
* WIP: Setting up C/Cpp source compilation targets. * WIP: Emitting C/CPP. * WIP: Split out SourceSink, and use it for source output on emit. * SourceSink -> SourceStream * * Made SourceStream use m_ prefixing of members. * Make all methods use lower camel * Removed methods from SourceStream interface that are not used externally (use _ prefixing) * Improvements to documentation * EmitContext is now effectively empty, so just use SharedEmitContext as EmitContext. * SharedEmitContext -> EmitContext * Methods to LowerCamel in emit.cpp * Split out EmitContext and ExtensionUsageTracker into separate files. * Split out EmitVisitor into slang-c-like-source-emitter files. * EmitVisitor -> CLikeSourceEmitter * Tidy up around CLikeSourceEmitter - simplify header. * Small tidy up - removing repeated comments that are in header. * Remove EmitContext paramter threading. * Small tidy up. Use prefixed macros for slang-c-like-source-emitter.h * Small tidy up in slang-c-like-source-emitter.cpp * First pass at splitting out UnmangleContext. * MangledNameParser -> MangledLexer. * WIP making EmitOp (EOp) enum available outside of cpp * Generating EmitOpInfo from macro. * Split out emit precedence handling. Don't use kOp_ style anymore, just use an array indexed by EmitOp. * Disable C simple test for now. * Keep g++/clang happy with token pasting. * Fix win32 narrowing warning.
2019-05-22Basic layout and reflection for specialized types (#970)Tim Foley
* Basic layout and reflection for specialized types Suppose I have an interface, and a simple implementation of it: ```hlsl interface IModifier { float modify(float value); } struct Doubler : IModifier { float modify(float value) { return 2 * value; } } ``` SAnd now suppose I want to define an implementation that recursively uses the same interface: ```hlsl struct MultiModifier : IModifier { IModifier first; IModifier second; float modify(float value) { value = first.modify(value); value = second.modify(value); return value; } } ``` And now consider that I might have a generic entry point that uses the interface: ```hlsl void myShader<M : IModifier>( uniform M modifier, ... ) { ... } ``` I can easily specialize `myShader` for `M = Doubler`, but in order to specialze it for `M = MultiModifier` I need a way to specify what the types of `MultiModifier.first` and `.second` should be. That is what the `spReflection_specializeType` function is used to do: take a type like `MultiModifier` and specialize it for, say, `first : Doubler` and `second : Doubler`. That function creates an `ExistentialSpecializedType` that records the base type (`MultiModifier`) and the specialization arguments (the concrete types plus the witness tables that prove they implement the required interfaces). The change that introduced that logic neglected to include an implementation of type layout for `ExistentialSpecializedType`, and also didn't add any support for the new kind of type through the reflection API. That is what this change seeks to rectify. When it comes to layout, a specialized type neeeds to apply layout to its base type (e.g., `MultiModifier`) with the appropriate existential type "slot" arguments bound, which luckily is stuff that type layout already supporst (to handle specialization of interface-type shader parameters). Unlike the case for interface-type shader parameters where the "primary" and "pending" data for a type get propagated up the chain and allocated to different places, a specialized type should be allocated contiguously (e.g., `myShader<M>` is going to assume that the type `M` occupies a contiguous range in memory). The type layout for a specialized type thus computes a layout that is more-or-less a structure type consisting of the "primary" data followed by the "pending" data. This gets wrapped up in a new `ExistentialSpecializedTypeLayout` class. The reflection API then needs to expose an `ExistentialSpecializedTypeLayout` as a new kind of type, and then also provide access to the relevant pieces. For the "base" type, I went ahead and re-used the `getElementType` entry point, just for simplicity (we can debate whether that or a new entry point is more appropriate/convenient). For the actual layout, all that was needed was a way to query the offset for where the "pending" data gets placed, and that is already conveniently encoded as a `VarLayout` field in the `ExistentialSpecializedTypeLayout`. With this change, specialized types are closer to being truly usable, although there is still missing logic in IR lowering because we need to make sure that explicitly specialized types are represented differently from types that are specialized based on global shader parameters. * fixup: review feedback
2019-05-22Translate .Load() to imageLoad() for Vulkan (#967)Tim Foley
* Translate .Load() to imageLoad() for Vulkan We were already emitting calls to `imageLoad()` and `imageStore` when a `RWTexture*` was used with `operator[]`: ```hlsl RWTexture2D<float> myTex; ... float value = myTex[xy]; // becomes an imageLoad myTex[xy] = value; // becomes an imageStore ``` However, we were *not* correctly handling the translation of an explicit `.Load()` operation: ```hlsl float value = myTex.Load(xy); ``` The `.Load()` operation was being translated to a GLSL `texelFetch` as it would be a for a `Texture2D`, and not to an `imageLoad()` as would make sense for a `RWTexture2D` (which becomes a GLSL `image2D`). This fix is confined to the stdlib, and is mostly a matter of emitting either `texelFetch` or `imageLoad` as the GLSL function name depending on the "access" of the resource type. It is messy code, but straightforward. One extra detail was that there had been logic to emit a `, 0` argument in the `texelFetch` calls in the non-read-only case, because `texelFetch` usualy requires an explicit mip-level argument and `.Load()` on a `RWTexture*` doesn't recieve an LOD parameter. This is a non-issue now that we are calling `imageLoad()` instead, because `imageLoad` doesn't need/want the extra argument. * fixup: change test baseline based on recent GLSL output changes * fixup: review feedback
2019-05-22Hotfix/improve glsl semantic conversion review (#968)jsmall-nvidia
* Small changes based on review * Remove the explicit 'nominal' tests * Made isValueEqual and isEqual on on IRConstant take a pointer * Small improvements to comments, and clarity of using 'nominal' * Simplify comparison by just using isTypeOperandEqual as basis for isTypeEqual * Use cross compile to test half-texture.slang on glsl * Don't need half-texture.slang.expected * Fix handling of nominal comparison based on review, ensuring that for nominal insts, they can only be compared by pointer.
2019-05-21Fix a buffer overrun that can occur when the last byte of the file is '\r' ↵Christopher Dannemiller
or '\n' and the by adjacent to the last character in the file in memory is '\r' or '\n'. (#969)
2019-05-21Hotfix/improve glsl semantic conversion (#965)jsmall-nvidia
* Specify glsl semantic format - such that conversions are possible from hlsl sematics. * Comment improvements. Give appropriate type in glsl for sv_tessfactor. Note that sv_tessfactor is not functional though. * Work in progress for comparison of types. * * Fix type comparison issues around the hash. * Fix tests whos output changed with use of isTypeEqual
2019-05-21Allow interface types to be used inside of structs (#966)Tim Foley
Previously, interface types were allowed to be used directly as function parameters, local variables, and global shader parameters. Using an interface type as a field of a `struct` type or a `cbuffer` declaration was not implemented. This change adds that support, and fixes several unrelated issues that caused problems in doing so. * The most important work here was adding a case for `IRStructType` to `maybeSpecializeBindExistentialsType` that creates a specialized variant of a `struct` type on-demand based on specialization operands. This logic loops over the fields of the original struct, and creates new fields by binding the existentials/interfaces in the type of each field. Caching is used to ensure that the same `struct` type specialized to the same operands should yield the same result. * To allow subsequent specialization to occur when a `struct` with interface-type fields is used, it was also necessary to specialize field-address and field-extract instructions in cases where the value that the field is being extracted from is a `wrapExistential`. * Similarly, we neede to make sure that the logic for specializing called functions based on the concrete types for interfaces in the argument list would also take into account `struct` types with existential-type fields inside of them. * Doing the above changes revealed some serious flaws in how the `ir-specialize.cpp` logic was tracking which instructions still needed to be processed. It had previously been assuming that it could assume any relevant instructions were on its work list, and when the work list went empty it could exit. This runs into two problems: (1) sometimes we create new instructions when specializing, and it may be impossible to ensure that all the new instructions (e.g., those created by utility routines in other files) get added to the work list, and (2) sometimes the instruction(s) that need to be re-visited when we specialize something aren't its direct users, but instead somethign that transitively depends on the instruction. These issues were fixed by two changes to the pass: (1) we now maintain a list of known "clean" instructions instead of implicitly using the work-list as a list of "dirty" instructions (so that implicitly any new instruction is dirty), and periodically iterating over all instructions to add the non-clean ones to the work list for processing, and (2) when an instruction is specialized/replaced we mark everything that transitively depends on it "dirty" (by removing it from the "clean" list). * Added some logic to "fix up" the type of an IR function after changes that might modify its parameter list. Failing to have this logic meant that certain types were still live (because they were referenced by a function type) that couldn't actually be emitted as legal HLSL/GLSL. * Added some special cases to IR instruction creation for `wrapExistential` and `BindExistentialsType` so that they act as no-ops when there are no "slots" providing specialization information. This helps avoid some special cases when specializing structure fields (since some fields specialization and others don't, so in general there are zero or more operands specific to each field). * Added a test case that uses an interface type in a `cbuffer`, as well as an interface type in a `struct` passed as an entry-point `uniform` parameter. * Fixed up some parts of the `.natvis` files to reflect naming changes from a previous PR and thus restore some of the useful Visual Studio debugging experience for Slang.
2019-05-20Changes required for application adoption of interface-type parameters (#963)Tim Foley
* A few changes required for application adoption of interface-type parameters There are a few small changes here that are all related in that they arose from trying to integrate support for specialization via global interface-type shader parameters into a real application. Allow querying the "pending" layout via reflection API ------------------------------------------------------ The naming here isn't ideal, and could probably use a round of "bikeshedding" to arrive at something better, but the basic idea is that when you have a type like: ``` struct MyStuff { int a; IFoo foo; int b; } ``` the fields `a` and `b` get allocated space directly in the "primary" layout for `MyStuff` (at offsets 0 and 4, with `sizeof(MyStuff) == 8`), but the `foo` field can't be allocated space until we know what concrete type will get plugged in there. If we have a concrete type in mind: ``` struct Bar : IFoo { int bar; } ``` then we can know how much space the `foo` field will take up, but we still can't allocate it space directly in `MyStuff`, because we already decided that `sizeof(MyStuff) == 8`. Now imagine we place some `MyStuff` values into constant buffers: ``` cbuffer X { MyStuff x; } cbuffer Y { MyStuff y; float4 z; } ``` In each case we know that we want to place the `MyStuff::foo` field at the end of the containing constant buffer so that it doesn't disrupt the layout of the existing fields. But that means that the offset of `MyStuff::foo` relative to the start of the `MyStuff` isn't fixed, because of unrelated fields like `z` that need to get in between. In our layout code, we handle this by having a notion of a "pending" layout. Once we know how `MyStuff::foo` will be specialized, we can compute both a "primary" and a "pending" layout for `MyStuff`, which basically treats it as if it were two distinct types: ``` struct MyStuff_Primary { int a; int b; } struct MyStuff_Pending { Bar foo; } ``` Layout for an aggregate type like the `X` or `Y` constant buffer then proceeds by computing an aggregate primary layout and an aggregate pending layout, and then finally a constant buffer or parameter block "flushes" all or part of the pending data by appending it to the primary data to get the final layout. What all this means is that a type like `MyStuff` will have two different layouts (a default one for the primary data and a "pending" one for any specialized interface-type fields), and a variable like `Y::y` will also have two variable layouts that specify offsets (one set of offsets for its primary part, and one set of offsets for its pending part). In order to handle interface-type fields with these layout rules, an application needs a way to query the "pending" part of a type or variable layout, which luckily gives it back just another type/variable layout. The API change here is minimal, although actually exploiting the new API correctly in application code could prove challenging. Allow creating of explicitly specialized types ---------------------------------------------- This feature isn't actually implemented all the way through the compiler (I just needed enough to make the API calls go through), but I've added support for specializing a type that has interface-type fields through the reflection API. This maps to an `ExistentialSpecializedType` in the AST, and I'm lowering it to the IR as a `BindExistentialsType`, although that isn't 100% correct for the future. This feature will require a future PR to actually flesh out the implementation work, but I'll wait until that is the sticking point on the application side before I do that. Introduce a tiny `Hasher` abstraction ------------------------------------- While implementing all the boilerplate for a new `Type` subclass (we really need to reduce that work...), I got fed up with how we do hash-code computation and introduced a small utility `Hasher` type that is intended to wrap up the idiom of combining hashes. For now this isn't a major change, but in the future I'd like to expand on the design a bit to clean up some of the warts around how we handle hashing: * The `Hasher` implementation can and should switch from maintaining a single `HashCode` as its state to something that contains a more complete state (larger than the hash code) and just hashes new bytes into that state as it goes. This should make it possible to implement a `Hasher` for more serious hash functions, whether MD5, CityHash, or whatever we decide is good default. * Things that are hashable shouldn't have a `getHashCode()` method, but instead should have something like a `hashInto(Hasher&)` method. This change would have the dual benefits that (1) a composite type can easily hash all the fields that contribute to its identity into the hasher with minimal fuss/boilerplate, and (2) the hashes for composite types will be of higher quality because they can exploit all the bits of the hasher's state to combine the fields, instead of restricting each sub-field to just the bits in a hash code. We should be able to incrementally improve the quality of our design there over future changes, but for now it probably isn't a critical priority. Fixes for legalization of existential types ------------------------------------------- There were some missing cases in the handling of type legalization, such that a global interface-type shader parameter that got specialized to a type that contains *only* resource-type fields would cause a crash in the legalization step. I added a test for this case, and then made `ir-legalize-types.cpp` account for this case (the code to handle it ias a bit of a kludge, and shows that the `declareVars()` routine there is getting to a level of complexity that is worrying. * fixup: review feedback
2019-05-15Improve handling of types of semantics in glsl (#964)jsmall-nvidia
* Attempt to improve the glsl handling of hlsl semantics by taking into account the underlying glsl type. * Improve comments around 'NV_VIEWPORT_MASK' on glsl.
2019-05-15The gl_primitiveID built in type is int, but can be uint on HLSL. The change ↵jsmall-nvidia
trys to cast for glsl targets to avoid glslang producing a type error. (#962)
2019-05-09IntSet -> UIntSet (#961)jsmall-nvidia
* * Fix warning in vk-swap-chain around use of Index. Rename _indexOf to _indexOfFormat. * Rename IntSet to UIntSet and put in own files slang-uint-set.h.cpp. Use UInt as the held type. * On UintSet setMax -> resizeAndClear. Doing so revealed bug in add. * Closer following of conventions - use kPrefix for constants (even though held in 'enum') * Small fixes/improvements * * Add some documentation to UIntSet methods * Use memset to set/reset bits * Fix some tabbing. Rename oldBufferSize -> oldCount * Fix tabs.
2019-05-01Fix bitwise And & Or for scalar bool (#960)Robert Stepinski
* Convert bitwise Or & And to logical operations on scalar bools * Test bitwise operations on scalar bools
2019-04-29String/List closer to conventions, and use Index type (#959)jsmall-nvidia
* List made members m_ Tweaked types to closer match conventions. * Use asserts for checking conditions on List. Other small improvements. * List<T>.Count() -> getSize() * List<T> Add -> add First -> getFirst Last -> getLast RemoveLast -> removeLast ReleaseBuffer -> detachBuffer GetArrayView -> getArrayView * List<T>:: AddRange -> addRange Capacity -> getCapacity Insert -> insert InsertRange -> insertRange AddRange -> addRange RemoveRange -> removeRange RemoveAt -> removeAt Remove -> remove Reverse -> reverse FastRemove -> fastRemove FastRemoveAt -> fastRemoveAt Clear -> clear * List<T> FreeBuffer -> _deallocateBuffer Free -> clearAndDeallocate SwapWith -> swapWith * List<T> SetSize -> setSize Reserve -> reserve GrowToSize growToSize * UnsafeShrinkToSize -> unsafeShrinkToSize Compress -> compress FindLast -> findLastIndex FindLast -> findLastIndex Simplify Contains * List<T> Removed m_allocator (wasn't used) Swap -> swapElements Sort -> sort Contains -> contains ForEach -> forEach QuickSort -> quickSort InsertionSort -> insertionSort BinarySearch -> binarySearch Max -> calcMax Min -> calcMin * Initializer::Initialize -> initialize List<T>:: Allocate -> _allocate Init -> _init IndexOf -> indexOf * * Put #include <assert.h> in common.h, and remove unneeded inclusions * Small refactor of ArrayView - remove stride as not used * getSize -> getCount setSize -> setCount unsafeShrinkToSize->unsafeShrinkToCount growToSize -> growToCount m_size -> m_count * Some tidy up around Allocator. * Use Index type on List. * Refactor of IntSet. First tentative look at using Index. * Made Index an Int Did preliminary fixes. Made String use Index. * Partial refactor of String. * String::Buffer -> getBuffer ToWString -> toWString * Small improvements to String. String:: Buffer() -> getBuffer() Equals() -> equals * Try to use Index where appropriate. * Fix warnings on windows x86 builds.
2019-04-29Initial support for the `precise` keyword (#958)Tim Foley
Fixes #858 The `precise` keyword exists in both HLSL and GLSL and when applied to a variable declaration is supposed to indicate that all computations that contribute to the value of that variable should not be altered based on "fast-math" optimizations. The main examples are that separate multiply and add operations should not be turned into fused multiply-add (fma) operations, and that operations cannot ignore the possibility of infinity or not-a-number values (e.g., by assuming that `x * 0.0f` is always `0.0f`). (Aside: it is possible that my understanding of what the semantics of `precise` are in HLSL and GLSL is imperfect so that either the GLSL variant isn't sufficient to provide the semantics of the HLSL keyword, or that the definition of "all computations that contribute" to a value isn't actually correct. We may need to revise this implementation based on subsequent learnings.) The basic idea here is to turn the AST `precise` keyword into a `[precise]` decoration in the IR and then emit that as a `precise` keyword again in the output. The main catch is that whereas most of our existing IR decorations apply to things like global shader parameters or `struct` members that usually stick around for the duration of compilation, `[precise]` will get slapped on local variables that will often get optimized away by our SSA pass. There are two ways a variable can get eliminated/replaced during the SSA pass: 1. A use of the variable can be replaced with an ordinary instruction that computes its value. 2. A use of the variable can be replaced with a reference to a "phi node" that will take on the appropriate value based on control flow. These two cases already had logic to copy a "name hint" decoration from the variable over to an instruction that will replace it, and I simply extended them to also propagate over a `[precise]` decoration. The test case added with this change intentionally constructs a case where `[precise]` needs to be propagated over to an SSA "phi node" in order to generate correct output code. The other gotcha is that we can emit variable declarations in various places in `emit.cpp`, and all of these needed to handle `[precise]`. Not only do we have actually local variables (`IRVar`), but we also have SSA phi nodes (`IRParam`), and then there are cases where an intermediate computation (an ordinary instruction) should be `[precise]` and thus we need to emit it as a temporary (not folding it into its use sites) and make sure that the temporary itself gets the `precise` keyword. I have manually confirmed that in the output SPIR-V, this change results in the `NoContraction` SPIR-V decoration being added to the relevant operations, and the output DXBC contains a multiply and an add in place of a multiply-add. The output DXIL does not show any obvious changes due to `precise`, although the exact order and operands of the math instructions emitted does differ when `precise` is added/removed. In all cases the output is equivalent to hand-written HLSL/GLSL with a `precise`-qualified local variable.
2019-04-29Enable appropriate GLSL extension for unbounded-size resource arrays (#957)Tim Foley
Fixes #941 The GLSL we were emitting for unbounded-size arrays was the obvious: ```hlsl // This HLSL: Texture2D t[]; ``` ```glsl // ... becomes this GLSL: texture2D t[]; ``` Unfortunately, the legacy GLSL behavior for an array without a declared size is what is called an "implicitly-sized" array, which means that it is assumed to actually have a fixed size, which is determined by the maximum integer constant value used to index into it (and only integer constants are allowed to be used when indexing into it). Users hadn't noticed the issue for a while, because most of our users who rely on unbounded-size arrays were also using the HLSL `NonUniformResourceIndex` function: ```hlsl float4 v = t[NonUniformResourceIndex(idx)].Sample(...); ``` When mapping such code to GLSL we use the `nonuniformEXT` qualifier added by the `GL_EXT_nonuniform_qualifier` extension, and it turns out that a secondary feature of that extension is that it changes the GLSL language semantics for arrays (of resources) with an unspecified size, so that they instead behave like we want. So users were happy and we were blissfully ignorant of the lurking issue. The problem is that as soon as a user neglects to use `NonUniformResourceIndex` (perhaps because an index really is uniform): ```hlsl cbuffer C { uint definitelyUniform; } ... float4 v = t[definitelyUniform].Sample(...); ``` Now the code we emit doesn't need `nonuniformEXT` so it doesn't enable `GL_EXT_nonuniform_qualifier` and the declaration of `t` now falls under the "implicitly-sized" array rules, and thus the code fails because `definitelyUniform` is being used as an index but is *not* an integer constant. The fix is pretty simple: when emitting a declaration of a global shader parameter to GLSL, we check if it is an unbounded-size array of resources and, if so, enable the `GL_EXT_nonuniform_qualifier` extension. We don't need any clever handling to deal with resource parameters nested in `struct` types or in entry-point parameter lists, etc., because previous IR passes will have split up complex types and moved everything to the global scope already.
2019-04-25Feature/build osx (#955)jsmall-nvidia
* * Moved CPU determination macros to slang.h * Determine SlangUInt/SlangInt from the pointer width (determined from CPU macros) * Removed the UnambiguousInt and UnambigousUInt types - as a previous fragile work around * Removed UInt/Int definition from smart-pointer.h as now in common.h * * Remove ambiguity for PrettyWriter and ints * Improve comment around SlangInt/UInt * More fixes around ambiguity with PrettyWriter and integral types. * Disable VK on OSX. * Define guids with inner braces. * For glslang use linux ossource for macosx. * Pull is ossource for OSX. * Fix dll loading for OSX. * Added how to build for OSX to building.md. * Force CI to rebuild as spurious error. * Improvements to the building.md documentation. * Small doc fix.
2019-04-25Feature/uint int definition (#954)jsmall-nvidia
* * Moved CPU determination macros to slang.h * Determine SlangUInt/SlangInt from the pointer width (determined from CPU macros) * Removed the UnambiguousInt and UnambigousUInt types - as a previous fragile work around * Removed UInt/Int definition from smart-pointer.h as now in common.h * * Remove ambiguity for PrettyWriter and ints * Improve comment around SlangInt/UInt * More fixes around ambiguity with PrettyWriter and integral types. * Disable VK on OSX. * Force CI to rebuild as spurious error.
2019-04-25Fixed building on CygWin with clang gcc (#953)jsmall-nvidia
* * Make Path:: use lowerCamel method names as per coding standard * Small improvements to make closer to standard * GetDirectoryName -> getParentDirectory - previous method name's action was somewhat unclear, hopefully this is better * * Can build on clang and gcc on CygWin * Fix problem on cygwin loading shared libraries * Renamed Path::isRelative to ::hasRelativeElement because isRelative implies the path is 'relative to the current path' and which isn't quite what it does * Documented how to build for CygWin * * Fix small bug creating platform shared library name. * Small typo fixes in building.md
2019-04-24* Make Path:: use lowerCamel method names as per coding standard (#952)jsmall-nvidia
* Small improvements to make closer to standard * GetDirectoryName -> getParentDirectory - previous method name's action was somewhat unclear, hopefully this is better
2019-04-23Feature/premake build (#951)jsmall-nvidia
* * Remove Makefile * Document how to create build using premake5 * Added support for finding the executable path * If binDir not set on command line use the executable path * Fix getting exe path on linux. * Removed CalcExecutablePath from Path:: interface, made implementation internal. * Documentation improvements. * Fixes based on review * Fix some typos * Removed unused/needed global
2019-04-23Fix 'unreachable code' stopping compilation on VS2017. (#949)jsmall-nvidia