9919c82 | Tim Foley | 06 November 2017, 18:37:27 UTC | Parameter blocks (#245) * Rename existing ParameterBlock to ParameterGroup We are planning to add a new `ParameterBlock<T>` type, which maps to the notion of a "parameter block" as used in the Spire research work. Unfortunately, the compiler codebase already uses the term `ParameterBlock` as catch-all to encompass all of HLSL `cbuffer`/`tbuffer` and GLSL `uniform`/`buffer`/`in`/`out` blocks (all of which are lexical `{}`-enclosed blocks that define parameters...). This change instead renames all of the existing concepts over to `ParameterGroup`, which isn't an ideal name, but at least doesn't directly overlap the new terminology or any existing terminology. The new `ParameterBlockType` case will probably be a subclass of `ParameterGroupType`, since it is a logical extension of the underlying concept. * Add Shader Model 5.1 profiles The HLSL `register(..., space0)` syntax is only allowed on "SM5.1" and later profiles (which is supported by the newer version of `d3dcompiler_47.dll` that comes with the Win10 SDK, but not the older version of `d3dcompiler_47.dll` - good luck figuring out which you have!). This change adds those profiles to our master list of profiles, and nothing else. * First pass at support for `ParameterBlock<T>` - Add the type declaration in stdlib - Add a special case of `ParameterGroupType` for parameter blocks - Handle parameter blocks in type layout (currently handling them identically to constant buffers for now, which isn't going to be right in the long term) - Add an IR pass that basically replaces `ParameterBlock<T>` with `T` - Eventually this should replace it with either `T` or `ConstantBuffer<T>`, depending on whether the layout that was computed required a constant buffer to hold any "free" uniforms - Add first stab at an IR pass to "scalarize" global variables using aggregate types with resources inside. - This currently only applies to global variables, so it won't handle things passed through functions, or used as local variables - It also only supports cases where the references to the original variable are always references to its fields, and not the whole value itself - Add a single test case that technically passes with this level of support, but probably isn't very representative of what we need from the feature * Fold parameter-block desugaring into a more complete "type legalization" pass The basic problem that was arising is that once you desugar `ParameterBlock<T>` into `T`, you then need todeal with splitting `T` into its constituent fields if it contains any resource types. Handling those transformations by following the usual use-def chains wasn't really helping, because you might need systematic rewriting that can really only be handled bottom-up. This change adds a new pass that is intended to perform multiple kinds of type "legalization" at once: - It will turn `ParameterBlock<T>` into `T` - It may at some point also convert `ConstantBuffer<T>` into `T` as well - It will turn an value of an aggregate type that contains resources into N different values (one per field) - As a result of this, it will also deal with AOS-to-SOA conversion of these types Legalization is applied to *every* function/instruction/value, so that it can make large-scale changes that would be tough to manage with a work list. This pass needs to be run *after* generics have been fully specialized, so that we know we are always dealing with fully concrete types, so that their legalization for a given target is completely known. This is still work in progress; there's more to be done to get this working with all our test cases, and finish the remaining `ParameterBlock<T>` work. * Improve binding/layout information when using parameter blocks - When doing type layout for a parameter block, don't include the resources consumed by the element type in the resource usage for the parameter block - Note that this is pretty much identical to how a `ConstantBuffer<T>` does not report any `LayoutResourceKind::Uniform` usage, except that `ParameterBlock<T>` is *also* going to hide underlying texture/sampler reigster usage - The one exception here is that any nested items that use up entire `space`s or `set`s those need to be exposed in the resource usage of the parent (I don't have a test for this) - When type legalization needs to scalarize things, it must propagate layout information down to the new leaf variables. In general, the register/index for a new leaf parameter should be the sum of the offsets for all of the parent variables along the "chain" from the original variable down to the leaf (we aren't dealing with arrays here just yet). - When type legalization decides to eliminate a pointer(-like) type (e.g., desugar `ParameterBlock<T>` over to `T`), actually deal with that in terms of the `LegalVal`s created, so that we can know to turn a `load` into a no-op when applied to a value that got indirection removed. - Hack up the "complex" parameter-block test so that it actually passes (the big hack here is that the HLSL baseline is using names that are generated by the IR, and are unlikely to be stable as we add/remove transformations). - Note: I can't make these be compute tests right now, because regsiter spaces/sets are a feature of D3D12/Vulkan, and our test runner isn't using those APIs. | 06 November 2017, 18:37:27 UTC |
296e89c | Yong He | 05 November 2017, 21:39:38 UTC | Merge pull request #243 from csyonghe/master Adding associated types | 05 November 2017, 21:39:38 UTC |
ff7c46a | Yong He | 05 November 2017, 10:49:42 UTC | small cleanups | 05 November 2017, 10:49:42 UTC |
0d250f0 | Yong He | 05 November 2017, 00:21:19 UTC | style fixes | 05 November 2017, 00:21:19 UTC |
6e4ba9b | Yong He | 05 November 2017, 00:07:47 UTC | naming cleanup | 05 November 2017, 00:07:47 UTC |
87c15d3 | Yong He | 04 November 2017, 23:41:31 UTC | move advanced test cases out of 'smoke' category | 04 November 2017, 23:41:31 UTC |
33d9f07 | Yong He | 04 November 2017, 23:19:23 UTC | cleanup useless code | 04 November 2017, 23:19:23 UTC |
aeb69cb | Yong He | 04 November 2017, 23:12:01 UTC | Merge remote-tracking branch 'refs/remotes/official/master' | 04 November 2017, 23:12:01 UTC |
c6fb1de | Yong He | 04 November 2017, 23:11:37 UTC | fixed last couple warnings under release/x64 build. | 04 November 2017, 23:11:37 UTC |
8c0a429 | Yong He | 04 November 2017, 22:45:42 UTC | fix warnings | 04 November 2017, 22:45:42 UTC |
a4fabfc | Yong He | 04 November 2017, 22:43:26 UTC | Merge remote-tracking branch 'refs/remotes/official/master' | 04 November 2017, 22:43:26 UTC |
215ce20 | Yong He | 04 November 2017, 22:43:03 UTC | fixes x64 warnings | 04 November 2017, 22:43:03 UTC |
00e0382 | Yong He | 04 November 2017, 22:07:26 UTC | merge | 04 November 2017, 22:07:26 UTC |
d1009d1 | Yong He | 04 November 2017, 22:07:09 UTC | merge with fixWarnings branch | 04 November 2017, 22:07:09 UTC |
1f9686c | Yong He | 04 November 2017, 21:03:00 UTC | determineEncoding bug fix | 04 November 2017, 21:03:00 UTC |
cb0a577 | Yong He | 04 November 2017, 20:54:44 UTC | bug fix | 04 November 2017, 20:54:44 UTC |
784bd91 | Yong He | 04 November 2017, 20:30:18 UTC | fix linux build | 04 November 2017, 20:30:18 UTC |
98d2f27 | Yong He | 04 November 2017, 20:27:50 UTC | gcc warning fix | 04 November 2017, 20:27:50 UTC |
a7dd782 | Yong He | 04 November 2017, 20:23:21 UTC | fix linux build | 04 November 2017, 20:23:21 UTC |
8d19b2b | Yong He | 04 November 2017, 20:15:15 UTC | Merge branch 'master' of https://github.com/shader-slang/slang | 04 November 2017, 20:15:15 UTC |
288841f | Yong He | 04 November 2017, 20:09:48 UTC | fixed all warnings | 04 November 2017, 20:09:48 UTC |
664e0da | Yong He | 04 November 2017, 19:37:40 UTC | fix all unreachable code warnings | 04 November 2017, 19:37:40 UTC |
31e7f84 | Yong He | 04 November 2017, 19:20:21 UTC | Passing both assoctype-simple and assoctype-complex test cases. | 04 November 2017, 19:20:21 UTC |
d803bf7 | Yong He | 04 November 2017, 19:19:24 UTC | enable -use-ir option when executing compute test cases. | 04 November 2017, 19:19:24 UTC |
0ed248a | Yong He | 04 November 2017, 19:17:57 UTC | Natvis file update for improved debugging view of IR constructs | 04 November 2017, 19:17:57 UTC |
3d90678 | Yong He | 04 November 2017, 19:17:08 UTC | Fix encoding detection when reading text file. Win32 API could mistakenly report UTF16 when the file is actually UTF8. | 04 November 2017, 19:17:08 UTC |
ba396cc | Yong He | 04 November 2017, 10:59:12 UTC | Merge https://github.com/shader-slang/slang | 04 November 2017, 10:59:12 UTC |
76db363 | Yong He | 04 November 2017, 10:57:48 UTC | work in-progress | 04 November 2017, 10:57:48 UTC |
0a36567 | Yong He | 03 November 2017, 22:55:03 UTC | associatedtypes: generating almost correct HLSL, but is not calling correctly mangled function. | 03 November 2017, 22:55:03 UTC |
cc98fd4 | Tim Foley | 03 November 2017, 19:25:46 UTC | Fix #248 (#249) * Fix up test runner output for compute. We want compute-based tests to produce a `.actual` file when compilation fails, so we can easily diagnose the issue. I thought I'd added this capability previous, but it seemst to not be present any more. * Compute result types for constructor decls Fixes #246 When the parser sees an `init()` declaration, it can't easily know what type is is supposed to return, so it leaves the type as NULL. This was causing some downstream crashes. Rather than special-case every site that cares about the result type of a callable, we will instead ensure that we install an actual result type on an initializer/constructor as part of its semantic checking. This code needs to handle both the case where the initializer is declared inside a type, as well as the case where it is declared inside an `extension`. | 03 November 2017, 19:25:46 UTC |
38ec0e0 | Yong He | 03 November 2017, 13:45:54 UTC | Merge remote-tracking branch 'refs/remotes/official/master' | 03 November 2017, 13:45:54 UTC |
8fe947b | Yong He | 03 November 2017, 13:42:44 UTC | Update natvis file for better viewing of RefPtr, DeclRef and Name classes | 03 November 2017, 13:42:44 UTC |
a045826 | Yong He | 03 November 2017, 13:38:02 UTC | in-progress work | 03 November 2017, 13:38:02 UTC |
d5e2319 | YONGH\yongh | 02 November 2017, 23:21:15 UTC | work inprogress | 02 November 2017, 23:21:15 UTC |
e2b9760 | YONGH\yongh | 01 November 2017, 18:05:33 UTC | remove assoctype-complex case to get pass test | 01 November 2017, 18:05:33 UTC |
134354c | Yong He | 01 November 2017, 17:16:26 UTC | Adding support for associated types. | 01 November 2017, 17:16:26 UTC |
b623864 | Yong He | 01 November 2017, 17:00:29 UTC | Merge https://github.com/shader-slang/slang | 01 November 2017, 17:00:29 UTC |
ec41631 | Tim Foley | 01 November 2017, 15:30:45 UTC | Allow use of dxc compiler for DXIL generation (#241) - Add shader model 6.0, 6.1, and 6.2 targets - Add DXIL and DXIL assembly as output formats - Add header for DXC API to `external/` - Add `dxc-support.cpp` that wraps usage of the API - Add `-pass-through dxc` option, equivalent to what we have for `fxc` Notes: * This does *not* include any logic to add `dxcompiler.dll` to our build process; that is way out of scope for the build complexity I'm ready to deal with * For right now, the use of `dxcompiler.dll` is hard-coded, and it must be discoverable in the current executable's search path; options to customize can come later * The `-pass-through` option is kind of silly because the code doesn't actually pay attention to the value (just whether it is set). If you set it to `fxc` but ask for DXIL, we pass through `dxc` anyway. | 01 November 2017, 15:30:45 UTC |
b475415 | Yong He | 31 October 2017, 15:13:00 UTC | merge | 31 October 2017, 15:13:00 UTC |
093bf1e | Yong He | 31 October 2017, 15:12:08 UTC | work in-progress: type checking associated types | 31 October 2017, 15:12:08 UTC |
e2b4730 | Yong He | 31 October 2017, 10:28:23 UTC | Merge pull request #240 from csyonghe/master Fixing issue #236 | 31 October 2017, 10:28:23 UTC |
8ba5d28 | Yong He | 31 October 2017, 09:56:28 UTC | initiate rebuild | 31 October 2017, 09:56:28 UTC |
436c906 | Yong He | 31 October 2017, 08:26:06 UTC | Revert "work in-progress, add parsing for assoc type decls and member type expressions" This reverts commit 84f381cc180b3176d6a58da4085ee8470f246922. | 31 October 2017, 08:26:06 UTC |
84f381c | YONGH\yongh | 31 October 2017, 01:18:20 UTC | work in-progress, add parsing for assoc type decls and member type expressions | 31 October 2017, 01:18:20 UTC |
91ac155 | YONGH\yongh | 30 October 2017, 23:40:13 UTC | Fixing issue #236 | 30 October 2017, 23:40:13 UTC |
832d9c7 | Yong He | 30 October 2017, 23:31:52 UTC | Merge pull request #235 from tfoleyNV/explicit-this-expr Support `this` expressions (explicit and implicit) | 30 October 2017, 23:31:52 UTC |
3ffdf61 | Tim Foley | 30 October 2017, 20:47:04 UTC | Merge branch 'master' into explicit-this-expr | 30 October 2017, 20:47:04 UTC |
c24c173 | Tim Foley | 30 October 2017, 18:17:20 UTC | Fix output for type cast when checking fails (#238) There were some cases where we would try to emit an `ErrorType` to the output HLSL, which obviously isn't allowed. This change tries to avoid emitting error types, and instead use the original expression when it is available. I tried adding a test case for the change, but I can't convince Slang to output matching line numbers for the error message; it seems like more work is needed on that front. | 30 October 2017, 18:17:20 UTC |
11f4424 | Tim Foley | 30 October 2017, 17:03:52 UTC | Allow for implicit `this` expressions. - When peforming ordinary lookup, if the container declaration for a scope is an aggregate type or `extension` decl, then use a "breadcrumb" to make sure that we use a `this` expression as the base of any resulting declaration reference - Add a test case for implicit `this` usage - Update constrained generic test case to use implicit `this` for member reference, as was originally intended | 30 October 2017, 17:26:22 UTC |
42f1cff | Tim Foley | 30 October 2017, 15:54:09 UTC | Support explicit `this` expressions This is the first step towards supporting traditional object-oriented method definitions; the second step will be to allow `this` expressions to be implicit. - Add a test case using explicit `this`, and expected output - Update parsing logic for expressions so that it handled identifiers similarly to the declaration and statement logic: first try to parse using a syntax declaration looked up in the curent scope, and otherwise fall back to the ordinary `VarExpr` case. * As long as I'm making that change: switch `true` and `false` to be parsed via the callback mechanism rather than be special-cased. * This change will also help out if we ever wanted to add `super`/`base` expressions, `new`, `sizeof`/`alignof` or any other expression keywords. - Add a `ThisExpr` node and register a parser callback for it. - Add semantic checks for `ThisExpr`: basically just look upwards through scopes until we find either an aggregate type declaration or an `extension` declaration, and then use that as the type of the expression. - TODO: eventually we need to guard against a `this` expression inside of a `static` member. - The IR generation logic already handled creation of `this` parameters in function signatures; the missing piece was to register the appropriate parameter in the context, so that we can use it as the lowering of a `this` expression. | 30 October 2017, 16:40:04 UTC |
4ab545b | Tim Foley | 27 October 2017, 18:22:11 UTC | Initial work on support code generation for generics with constraints (#233) This change includes a lot of infrastructure work, but the main point is to allow code like the following: ``` // define an interface interface Helper { float help(); } // define a generic function that uses the interface float test<T : Helper>( T t ) { return t.help(); } // define a type that implements the interface struct A : Helper { float help() { return 1.0 } } // define an ordinary function that calls the // generic function with a concrete type: float doIt() { A a; return test<A>(a); } ``` Getting this to generate valid code involves a lot of steps. This change includes the initial version of all of these steps, but leaves a lot of gaps where more complete implementation is required. The changes include: - Member lookup on types has been centralized, and now handles the case where the type we are looking for a member in is a generic parameter (e.g., given `t.help()` we can now look up `help` in `Helper` by knowing that `t` is a `T` and `T` conforms to `Helper`). - There is an obvious cleanup still to be done here where the same exact logic should be used to look up available "constructor" declarations inside a type when the type is used like a function. - Add a notion of subtype constraint "wittnesses" to the type system. When a generic is declared as taking `<T : Helper>` it really takes two generic parameters: the type `T` and a proof that `T` conforms to `Helper`. The actual arguments to a generic will then include both the type argument and a suitable witness argument (both type-level values). - As it stands right now, a witness wraps a `DeclRef` to the declaration that represents the appropriate subtype relationship. So if we have `struct A : Helper`, that `: Helper` part turns into an `InheritanceDecl` member, and a reference to that member can serve as a witness to the fact that `A` conforms to `Helper`. - Make explicit generic application `G<A,B>` synthesize the additional arguments that represent conformances required by the generic. - This does *not* yet deal with the case where a generic is implicitly specialized as part of an ordinary call `G(a,b)` - A bug fix to not auto-specialize generics during lookup. The problem here was related to an attempted fix of an earlier issue. During checking of a method nested in a generic type, we were running into problems where `DeclRefType::create()` was getting called on an un-specialized reference to `vector`, and this was leading to a crash when the code looked for the arguments for the generic. This was worked around by having name lookup automatically specialize any generics it runs into while going through lookup contexts. That choice creates the problem that in a generic method like this: ``` void test<T>(T val) { ... } ``` any reference to `val` inside the body of `test` will end up getting specialized so that it is effectively `test<T>::val`, when that isn't really needed. - Add front-end logic to check that when a type claims to conform to an interface it actually must provide the methods required by the interface. The checking process goes ahead and builds a front-end "witness table" that maps declarations in the interface being conformed to over to their concrete implementations for the type. - At the moment the checking is completely broken and bad: it assumes that *any* member with the right name is an appropriate declaration to satisfy a requirement. That obviously needs to be fixed. - Add an explicit operation to the IR for lookup of methods: `lookup_interface_method(w, r)` where `w` is a reference to the "witness" value and `r` is an `IRDeclRef` for the member we want to look up. - Add an explicit notion of witness tables to the IR. These end up being the IR representation of an `InheritanceDecl` in a type, and they are generated by enumerating the members that satisfy the interface requirements (which were handily already enumerated by the front-end checking). The witness table is an explicit IR value, and so it will be referenced/used at the site where conformance is being exploited (e.g., as part of a `specialize` call), so it should be safe to eliminate witness tables that are unused (since they represent conformances that aren't actually exploited). Similarly, the entries in a witness table are uses of the functions that implement interface methods, and so keep those live. - In order to implement the above, I did a bit of a cleanup pass on the IR representation so that there is an `IRUser` base that `IRInst` inherits from, so that we can have users of values that aren't instructions. - One annoying thing is that because of how types and generics are handled in the IR, we needed a way to have a type-level `Val` that wraps an IR-level value: e.g., to allow an IR-level witness table to be used as one of the arguments for specialization of a generic. The design I chose here is to have a "proxy" `Val` subclass (`IRProxyVal`) that wraps an `IRValue*`. These should only ever appear as part of types and `DeclRef`s that are used by the IR. - One annoying bit here is that an IR value might then have a use that is not manifest in the set of IR instructions, and instead only appears as part of a type somewhere. - I'm not 100% happy with this design, but it seems like we'd have to tackle similar issues if/when we eventually allow functions to have `constexpr` or `@Constant` parameters - Make generic specialization also propagate witness table arguments through to their use sites (this is mostly just the existing substitution machinery, once we have `IRProxyVal`), and then include logic to specialize `lookup_interface_method` instructions when their first operand is a concrete witness table. All of this work allows a single limited test using generics with constraints to pass, but more work is needed to make the solution robust. | 27 October 2017, 18:22:11 UTC |
56bc826 | Yong He | 26 October 2017, 03:16:53 UTC | Merge pull request #230 from csyonghe/master Finish up implementation of render-test | 26 October 2017, 03:16:53 UTC |
3a7dcf6 | YONGH\yongh | 26 October 2017, 02:58:24 UTC | ignore RENDER_COMPUTE test cases in linux build. | 26 October 2017, 02:58:24 UTC |
1981c92 | YONGH\yongh | 26 October 2017, 02:23:02 UTC | render-test code cleanup | 26 October 2017, 02:23:02 UTC |
14d93b0 | YONGH\yongh | 26 October 2017, 02:13:11 UTC | fix d3d11 usage | 26 October 2017, 02:13:11 UTC |
9a28965 | YONGH\yongh | 26 October 2017, 01:44:42 UTC | test | 26 October 2017, 01:44:42 UTC |
9a120fc | YONGH\yongh | 26 October 2017, 01:32:28 UTC | test | 26 October 2017, 01:32:28 UTC |
ab1009c | YONGH\yongh | 26 October 2017, 01:08:29 UTC | test | 26 October 2017, 01:08:29 UTC |
052645e | YONGH\yongh | 26 October 2017, 01:03:52 UTC | test | 26 October 2017, 01:03:52 UTC |
785cb48 | YONGH\yongh | 26 October 2017, 00:38:00 UTC | test | 26 October 2017, 00:38:00 UTC |
24bb556 | YONGH\yongh | 26 October 2017, 00:35:57 UTC | test | 26 October 2017, 00:35:57 UTC |
23e3217 | YONGH\yongh | 26 October 2017, 00:18:25 UTC | test | 26 October 2017, 00:18:25 UTC |
cb83698 | YONGH\yongh | 26 October 2017, 00:13:45 UTC | test | 26 October 2017, 00:13:45 UTC |
52ceff4 | YONGH\yongh | 25 October 2017, 21:59:45 UTC | add new test mode: COMPARE_RENDER_COMPUTE, which runs a input vertex/fragment shader pair, but instead of comparing the resulting framebuffer, it expects the test shader to write results into a UAV, and compares the pixel shader UAV output to the reference output. | 25 October 2017, 21:59:45 UTC |
922c17b | YONGH\yongh | 25 October 2017, 20:33:59 UTC | Merge https://github.com/shader-slang/slang | 25 October 2017, 20:33:59 UTC |
5894c3b | YONGH\yongh | 25 October 2017, 20:33:18 UTC | finish up opengl renderer implementation for input resource binding. | 25 October 2017, 20:33:18 UTC |
3043171 | Yong He | 24 October 2017, 23:14:14 UTC | Merge pull request #227 from csyonghe/master Extending render-test to support various resource inputs | 24 October 2017, 23:14:14 UTC |
434d342 | Yong He | 24 October 2017, 03:42:23 UTC | bug fix | 24 October 2017, 03:42:23 UTC |
19c4119 | Yong He | 24 October 2017, 03:31:17 UTC | test 7 | 24 October 2017, 03:31:17 UTC |
ff4f9d9 | Yong He | 24 October 2017, 03:13:37 UTC | test 6 | 24 October 2017, 03:13:37 UTC |
deba0d8 | Yong He | 24 October 2017, 03:08:12 UTC | test 5 | 24 October 2017, 03:08:12 UTC |
84683a9 | Yong He | 24 October 2017, 02:58:24 UTC | test 4 | 24 October 2017, 02:58:24 UTC |
809f2bb | Yong He | 24 October 2017, 02:24:23 UTC | try fix 3 | 24 October 2017, 02:24:23 UTC |
2f549e9 | Yong He | 24 October 2017, 02:20:56 UTC | try fix 2 | 24 October 2017, 02:20:56 UTC |
fd22e8a | Yong He | 24 October 2017, 01:57:59 UTC | test | 24 October 2017, 01:57:59 UTC |
61624e3 | Yong He | 24 October 2017, 01:48:20 UTC | attempt to fix | 24 October 2017, 01:48:20 UTC |
0ed979e | Yong He | 24 October 2017, 01:40:53 UTC | Merge https://github.com/shader-slang/slang | 24 October 2017, 01:40:53 UTC |
9882956 | Yong He | 24 October 2017, 01:40:14 UTC | test | 24 October 2017, 01:40:14 UTC |
ab64cf2 | Tim Foley | 23 October 2017, 17:37:07 UTC | Fix output for matrix multiple in GLSL code (#228) When Slang sees a matrix multiplication `M * v` in GLSL code it should (obviously) output GLSL code that also does `M * v`, but there was a bug introduced where the type-checker manages to resolve the operation and recognize it as a matrix-vector multiply, and then the code-generation logic says "oh, I'm generating output for GLSL, and that is reversed from HLSL/Slang, so I'd better reverse these operands!" and outputs `v * M`... which isn't what we want. I've fixed the problem in an expedient way, by having the front-end resolve the operation to what it believes is an intrinsic multiply operation, rather than a matrix-vector operation. If we ever support cross compilation *from* GLSL (unlikely), we've need to fix this up so that we have both real matrix-vector multiplies and "reversed" multiplies where the operands folow the GLSL convention). I've added two tests here to confirm the fix. The one under `tests/bugs` catches the actual issue described above, and confirms the fix. The other one under `tests/cross-compile` is just to make sure that we *do* properly reverse the operands to a matrix-vector product when converting from Slang to GLSL. | 23 October 2017, 17:37:07 UTC |
c68224e | Yong He | 23 October 2017, 15:25:44 UTC | try fix linux build | 23 October 2017, 15:25:44 UTC |
3c64961 | Yong He | 23 October 2017, 15:10:40 UTC | fix test case | 23 October 2017, 15:10:40 UTC |
c8bda84 | Yong He | 23 October 2017, 14:53:17 UTC | fix compute shader test result comparison | 23 October 2017, 14:53:17 UTC |
4d6be35 | Yong He | 23 October 2017, 14:44:08 UTC | Merge https://github.com/shader-slang/slang | 23 October 2017, 14:44:08 UTC |
cc6184e | Yong He | 23 October 2017, 14:35:44 UTC | Work in-progress: simple compute test passed. (d3d renderer) | 23 October 2017, 14:35:44 UTC |
0c8efd1 | YONGH\yongh | 20 October 2017, 23:12:47 UTC | work in progress | 20 October 2017, 23:12:47 UTC |
0ee4d4b | YONGH\yongh | 20 October 2017, 22:24:30 UTC | in-progress work: allow render-test to generate and bind various resource inputs for running test shaders with arbitrary parameter definitions. This commit contains the parser of the resource input definition. | 20 October 2017, 22:24:30 UTC |
624d122 | Tim Foley | 20 October 2017, 22:16:10 UTC | Fix up emission of shader parameter semantics when using IR (#226) * Fix up emission of shader parameter semantics when using IR - Make sure to propagate entry point parameter layouts down to IR parameters when doing the initial cloning to form target-specific IR - When layout information is present on an IR node, prefer to use that over the original high-level declaration for outputting semantics in final HLSL - Fix up test runner to generate `.actual` files when running compute tests, in cases where the `render-test` application errors out (e.g., because of a Slang compilation error) - Add a first test of generics functionality, to show that they generate valid code through the IR - Right now this test is *not* using any "interesting" operations on the type parameter, so this is not a test that can confirm that interface constraints work * fixup: skip compute tests when running on Linux | 20 October 2017, 22:16:10 UTC |
7ba937f | Yong He | 19 October 2017, 23:38:07 UTC | Merge pull request #225 from csyonghe/master Support running compute shaders in testing framework | 19 October 2017, 23:38:07 UTC |
5a18dc7 | YONGH\yongh | 19 October 2017, 22:20:29 UTC | typo fix | 19 October 2017, 22:20:29 UTC |
8ff7412 | YONGH\yongh | 19 October 2017, 22:18:21 UTC | Support running and comparing execution results of compute shaders in testing framework. | 19 October 2017, 22:18:21 UTC |
88023ae | Tim Foley | 19 October 2017, 18:49:16 UTC | Reflection: allow querying of semantics on varying input/output (#224) This is functionality required to support a Falcor bug fix. Most of the code to compute the right semantic name/index for a parameter was already present. This change adds: - Storage for semantic name/index on every `VarLayout` - Note: this is wasteful and should be optimized later - A public API to query the semantic name/index - The contract is that this API returns `NULL` if the parameter had no semantic - A bit of work in `parameter-binding.cpp` to attach semantics to varying input/output when traversing varying parameters. - Note: this is intentionally set up so that it associates semantics even with non-leaf parameters, so that an API user can query the semantic of a `struct` parameter and know that its members will be assigned sequential semantic indices from its starting value. - Support for dumping this information in reflection tests One notable thing that I did *not* change here is that the reflection test fixture doesn't report information on the output of an entry point, even though it really should. That should be fixed in a separate change, though, because it would affect many of the expected outputs. | 19 October 2017, 18:49:16 UTC |
5995b7a | Tim Foley | 19 October 2017, 16:04:41 UTC | Initial work on a pass to scalarize GLSL varying input/output (#223) There was already a pass in place that transformed parameters and results of an entry-point function into global variables for GLSL, but this pass would just turn a `struct`-type parameter into a `struct`-type global, which has two problems: - The standard GLSL language doesn't seem to allow `struct` types as vertex shader inputs or fragment shader outputs. - If there are any members in such a `struct` that represent "system value" inputs or outputs, then these would need to be transformed into the equivalent `gl_*` variables. This change adds a more complete scalarization process that applies to inputs/outputs during the legalization pass. In order to support this there is a little bit of a data strcuture for abstracting over tuples of values (this same idiom is used in a few other places, so perhaps the implementation could be done once and shared?). System values are current handled in a painfully ad hoc (and incomplete) fashion during code emit. We need to come up with a better solution for mapping HLSL `SV_*` semantics over to `gl_*` variables. In some cases this mapping might introduce more code than we can easily deal with during emit time, so it probably needs to be handled back at the IR level. This implementation has many gaps, but it appears to be enough to get teh `render/cross-compile-entry-point` test working with IR-based cross-compilation. | 19 October 2017, 16:04:41 UTC |
a12480f | Tim Foley | 18 October 2017, 18:08:47 UTC | Work on IR-based cross-compilation (#222) There are two big changes here: - Add logic during the initial IR cloning pass for an entry point + target that tries to pick the best possible version of any target-overloaded function. This allows us to pick the intrinsic version of `saturate()` when compiling for HLSL output, but then pick the non-intrinsic version (that is implemented in terms of `clamp()`) when targetting GLSL. - Add an initial specialization pass that tries to deal with generics. This required some fixing work to IR generation, so that we correctly generate explicit operations to specialize a generic for specific types (this is currently implemented as a `specialize` instruction that takes the generic to specialize plus a declaration-reference that represents the specialized form). With that work in place, we can scan for `specialize` instructions inside of non-generic functions, and use them to trigger generation of specialized code. We rely on the name-mangling scheme to help us find pre-existing specializations when possible. There are also a bunch of cleanups encountered along the way: - Don't use the explicit `layout(offset=...)` for uniforms, because it isn't supported by all current drivers. For now we will just assume that our layout rules compute the same values that the driver would for un-marked-up code. We can come back later and try to implement a workaround in the cases where this doesn't apply (e.g., by re-running the layout logic as part of emission, and dropping layout modifiers from variables that don't need explicit layout). - Fix some issues in IR dump printing so that we print function declarations more nicely. - Testing: print out failing pixel when image-diff fails | 18 October 2017, 18:08:47 UTC |
f12c255 | Tim Foley | 16 October 2017, 20:12:11 UTC | Implement notion of a "container format" (#213) The big addition here is that the Slang "bytecode" is no longer treated as just a "code generation target" (`CodeGenTarget`) akin to DX bytecode (DXBC) or SPIR-V, but instead is a `ContainerFormat` that can be used to emit all the results of a compile request (well, currently just the IR-as-BC, but the intention is there). Getting to this goal involved some prior checkins that eliminated bogus "targets" that weren't really akin to SPIR-V or DXBC: `-target slang-ir-asm` and `-target reflection-json`. Those targets were really in place to support testing, and so they've been made more explicit testing/debug options. This change eliminates `-target slang-ir` and instead tries to allow the user to specify `-o foo.slang-module` as an output file name, that indicates the intention to output a "container" file that will wrap up all the generated code. I've also gone ahead and generalized the existing `-target` option so that we are actually building up a *list* of code generation targets. This is largely just a cleanup, since it forces code to be more aware of when it is doing something target-specific vs. target independent. For example, reflection layout information lives on a requested target, and not on the compile request as a whole, and similarly output code is per-target, per-entry-point. As a cleanup, I eliminated support for per-translation-unit output. This was vestigial code from back when I used to try and do HLSL generation for a whole translation unit instead of per-entry-point (which turned out to be a lot of complexity for little gain), and it was only being used in the `hello` example and the `render-test` test fixture - in both cases fixing it up was easy enough. I've stubbed out the old `spGetTranslationUnitSource` API, but haven't removed it yet. | 16 October 2017, 20:12:11 UTC |
3e3e247 | Tim Foley | 14 October 2017, 05:39:15 UTC | Get rid of the `-slang-ir-asm` target (#212) * Get rid of the `-slang-ir-asm` target This is really only useful for debugging, so I've replaced the functionality with a `-dump-ir` command line option (which dump's the IR for an entry point before doing codegen). * fixup: use HLSL target, not DXBC, so test can run on Linux | 14 October 2017, 05:39:15 UTC |
64ddefb | Tim Foley | 14 October 2017, 01:14:42 UTC | Move reflection JSON generation into separate text fixture (#211) Move reflection JSON generation into separate test fixture | 14 October 2017, 01:14:42 UTC |
575230b | Tim Foley | 12 October 2017, 20:53:42 UTC | Work towards target-specific function overloads (#210) * Checkpoint: interface conformance work - Add explicit definition of `saturate` for the GLSL target, which calls through to `clamp` - Needed to add explicit initializer to `__BuiltinFloatingPointType` to allow initialization from a single `float`, so that the `saturate` implementation can be sure that it can initialize a `T` from `0.0` or `1.0`. - This triggered errors in overload resolution, because the logic in place could not figure out that the `T` of the outer generic (`saturate<T>()`) conformed to the interface required by the callee. At this point I have the call to the scalar `clamp()` getting past type-checking, but not the vector or matrix cases. * More fixups for overload resolution inside generics - Make sure value parameters are treated the same as type parameters: we only want to solve for the parameters of the generic actually being applied, and not accidentally generate constraints for outer generics (e.g., when checking the body of a generic function). - Make sure that the diagnostics stuff uses the correct source manager when expanding the location of a builtin. * Fixes for function redeclaration - Handle case of redeclaring a generic function - Enumerate siblings in the parent of the *generic* not the parent of the *function* - Add logic to compare generic signatures - When generic signatures match, specialize functions to compatible generic arguments before comparing the function signatures - Fix redeclaration logic to *not* detect prefix/postifx operators as redeclarations of one another - Build an explicit representation of function redeclaration groups - First declaration is the "primary" and others are stored in a linked list - Make overload resolution handle redeclared functions - Only consider the primary declaration and skip others | 12 October 2017, 20:53:42 UTC |
9a231a5 | Tim Foley | 12 October 2017, 17:30:48 UTC | Do loop fix (#209) * Bug fix: emit logic for `do` loops This case was never tested, and I was outputting some garbage characters. This comit fixes the codegen and adds a test case. * Bug fix: make sure to pass through `[allow_uav_condition]` This also fixes the standard library definition of `IncrementCounter()` so that it returns a `uint` instead of `void`. | 12 October 2017, 17:30:48 UTC |
28ca4dc | Tim Foley | 11 October 2017, 23:05:09 UTC | Fixup: re-enable exception guard (#208) This is intended to produce a better experience for end users when they encounter internal compiler errors. | 11 October 2017, 23:05:09 UTC |
331ddfa | Tim Foley | 11 October 2017, 21:39:10 UTC | Bug fixing (#207) * Bug fix for vector initializer lists When a vector was initialized with an initializer list: float4 f = { 0, 1, 2, 3 }; we were following the logic for `struct` types (since `vector<T,N>` is technically a `struct` declaration in our stdlib...), but the type has no field, so we were (silently!) ignoring the actual operands. I've applied a simple fix where we cast the operands to the element type of the vector, but a more complete fix will be needed sooner or later where we check the operand counts properly, etc. * Create implicit cast AST nodes when calling initializers The logic for dealing with implicit conversions was recently beefed up so that it would look at `__init` declarations in the target type, but in those cases the front-end would always create an `InvokeExpr` even when we would rather get an `ImplicitCastExpr` or (in the "rewrite" case) a `HiddenImplicitCastExpr`. I've fixed this up for now by constructing a dummy expression to stand in for the "original" call expression when creating the final call (luckily our `TypeCastExpr` is already just a specialized `InvokeExpr`). A better long-term solution might be to have implicit-ness or hidden-ness be modifiers or flags, rather than needing to use specialized forms of call nodes. * Fix subscript operator for `RWTexture1D` The index type was being declared as `uint1` instead of `uint`, and that created problems for downstream HLSL compilation when we introduced expressions like `uav[uint1(index)]` - the compiler would complain that a vector is not a valid index type. * Fix up constant-folding of integer casts. The old logic was checking for `InvokeExpr` before `TypeCastExpr`, but in the new setup a type cast *is* an `InvokeExpr`, so that case was never triggering. All of the constant-folding code really needs to be revisited, though, so that it can use a more general-purpose evaluation scheme like the bytecode (so that we can handle a moral equivalent of `constexpr` in the long run). * Fix implicit conversion costs for vector types A recent change made it so that the logic for looking up implicit conversions now uses declarations of initializers in the standard library (rather than hand-coding all the cases in `check.cpp`). One mistake made there was that we dropped the logic for computing implicit conversions between vectors of the same size, but different element types. These conversions were still allowed by a catch-all (generic) declaration in the standard library, but that declaration didn't include any implicit conversion cost logic (since it was generic, there was no single cost to use). This change explicitly enumerates the required conversions with their costs. It is a bit unfortunate that this is an O(N^2) amount of code for N base types, but that seems unavoidable for now. * Handle "lowering" of overloaded expressions If we are in the `-no-checking` mode and the user calls an overloaded function from an `__import`ed file in a way such that Slang can't resolve the intended overload, we were failing to emit the definitions of the potential callees. This change simply adds a case for `OverloadedExpr` in `lower.cpp` that explicitly lowers all the declarations that might have been referenced. - There is a potentially for breakage here if we are outputting GLSL and one of the overloads is stage-specific. - A more refined approach might try to recognize which over the overloaded options are even potentially applicable, and then output only those, but doing this would be way more complicated. I've added a test case for this behavior, but it is a bit brittle because we need to confirm that we still produce the same error message as unmodified HLSL. | 11 October 2017, 21:39:10 UTC |