{"push_id":2453553565,"size":11,"distinct_size":2,"ref":"refs/heads/master","head":"499e2586cba2a7ba2a703b90c459b24620e351ee","before":"2f35a819e1c9d3dede471f7ef8b1f0ff60297a1d","commits":[{"sha":"6d400b6944c56dbe0d5507288a2944e2f1710821","author":{"name":"jsmall-nvidia","email":"9bca19b6fb246b400fbd8bc3e81fbfcf8e88f975@nvidia.com"},"message":"Fix signed/unsigned comparison warning. (#455)","distinct":false,"url":"https://api.github.com/repos/jsmall-nvidia/slang/commits/6d400b6944c56dbe0d5507288a2944e2f1710821"},{"sha":"17b66ef006cd15f822284b7f8fe4a45d77e75944","author":{"name":"Tim Foley","email":"4483be28d7b118b23be41d8cd38a24491f0ef11e@users.noreply.github.com"},"message":"Unify all generic parameters, even if some mismatch (#454)\n\n* Fix decl-ref printing to handling NULL pointers\r\n\r\nIf the underlying decl, or its name is NULL, then use an empty string for the declaration name.\r\nThis issue was found when debugging, but could bite non-debug cases too, if we ever try to print something like a generic type constraint, which has no name.\r\n\r\n* Unify all generic parameters, even if some mismatch\r\n\r\nFixes #449\r\n\r\nThe front end tries to infer the right generic arguments to use at a call site using a sloppily implemented \"unification\" approach. The basic idea is that if you pass a `vector<float,3>` into a function that operates ona `vector<T,N>` where `T` and `N` are generic paameters, then the unification will try to unify `vector<float,3>` with `vector<T,N>` which will lead to it recursively unifying `float` with `T` and `3` with `N`, at which point we have viable values to substitute in for those parameters.\r\n\r\nWhere the existing approach is maybe not quite right is in how it handles obvious unification failures. So if we ask the code to unify, say, `float` with `uint`, it will bail out immediately because those can't be unified. This sounds right superficially, but in some cases with might be calling a function that takes a `vector<float,N>` and passing a `vector<uint,3>` and we'd like to at least get far enough along with unification to see that `N` should be `3` so that the front end can maybe decide to call the function anyway, with some amount of implicit conversion.\r\n\r\nOver time I've had to modify a lot of the \"unification\" logic so that it doesn't treat the obvious failures as a hard stop, and instead just returns the failure as a boolean status, but keeps on trying to unify things even after such a failure. When doing unification as part of inference for generic arguments, there will usually be subsequent steps (e.g., type conversions for function aguments) that will catch the type errors that arise.\r\n\r\nThis specific change is to make is so that when unifying the substitutions for a generic decl-ref, we try to unify all the pair-wise arguments, and don't bail out on the first mismatch (so that the `float`-vs-`uint` failure above doesn't lead to us skipping the `3` and `N` pairing).\r\n\r\nThe one case we need to watch out for in all of this is when unification is used to check if an `extension` declaration (which might be generic) is actually application to a concrete type. In that case we obviously don't want an extension for `vector<float,N>` to apply to `vector<uint,3>`, so it is important that the extension case check the return status from the unification logic (*or* in the future, it could just confirm that the substituted type is equivalent to the original as a post-process...).\r\n\r\nI've added a test case that reproduces the original failure that surfaced the bug.\r\n\r\n* fixup: add expected test output","distinct":false,"url":"https://api.github.com/repos/jsmall-nvidia/slang/commits/17b66ef006cd15f822284b7f8fe4a45d77e75944"},{"sha":"184dc5cd6998b6277881fae4a68d91de86e2d63f","author":{"name":"Tim Foley","email":"4483be28d7b118b23be41d8cd38a24491f0ef11e@users.noreply.github.com"},"message":"Merge from v0.9.15 (#460)\n\n* Fix bug when subscripting a type that must be split (#396)\r\n\r\nThe logic was creating a `PairPseudoExpr` as part of a subscript (`operator[]`) operation, but neglecting to fill in its `pairInfo` field, which led to a null-pointer crash further along.\r\n\r\n* Allow writes to UAV textures (#416)\r\n\r\nWork on #415\r\n\r\nThis issue is already fixed in the `v0.10.*` line, but I'm back-porting the fix to `v0.9.*`.\r\nThe issue here was that the stdlib declarations for texture types were only including the `get` accessor for subscript operations, even if the texture was write-able.\r\n\r\nI've also included the fixes for other subscript accessors in the stdlib (notably that `OutputPatch<T>` is readable, but not writable, despite what the name seems to imply).\r\n\r\n* Fix infinite loop in semantic parsing (#424)\r\n\r\nThe code for parsing semantics was looking for a fixed set of tokens to terminate a semantic list, rather than assuming that whenever you don't see a `:` ahead, you probably are done with semantics. This meant that you could get into an infinite loop just with simple mistakes like leaving out a `;`.\r\n\r\nThis change fixes the parser to note infinite loop in this case, and adds a test case to verify the fix.\r\n\r\n* Expose HLSL `shared` modifier through reflection. (#436)\r\n\r\nThis is a request from Falcor, because the `shared` modifier can be used as a hint to optimize the grouping of parameters for binding. The intention is that `shared` marks shader parameters (including parameter blocks) that will us the same values across many draw calls (e.g., per-frame data, as opposed to per-model or per-instance).\r\n\r\nThe mechanism I'm using here is to provide a general reflection API for exposing the `Modifier`s already attached to declarations. While the only modifier exposed is `shared`, and the only modifier information being exposed is presence/absence, this interface could be extended down the line.","distinct":false,"url":"https://api.github.com/repos/jsmall-nvidia/slang/commits/184dc5cd6998b6277881fae4a68d91de86e2d63f"},{"sha":"b4c4dc92c0b21f0253c4ccf34107638f7c36b62e","author":{"name":"Tim Foley","email":"4483be28d7b118b23be41d8cd38a24491f0ef11e@users.noreply.github.com"},"message":"Add support for default parameter values in IR codegen (#459)\n\nFixes #61\r\n\r\nWhen lowering from AST to IR, if a call site doesn't supply an argument expression for each of the parameters to the callee, then use the default value expressions (stored as the \"initializer\" of the parameter decl) for each omitted parameter. This relies on the front-end to have already checked the call site for validity.\r\n\r\nAlong the way I also cleaned up some of the checking of parameter declarations so that it is more like the checking of ordinary variable declarations (although the code is not yet shared). I also cleaned out some dead cases in the lowering logic for when we don't actually have a declaration available for a callee (these would only matter if we supported functions as first-class values).\r\n\r\nI added a simple test case to confirm that call sites both with and without the optional parameter work as expected.\r\n\r\nThe strategy in this change is extremely simplistic, and might only be appropriate for default parameter value expressions that are compile-time constants (which should be the 99% case). This may require a major overhaul if we decide to handle default parameter values differently (e.g., by generating extra functions to ensure that the separate compilation story is what we want).\r\n\r\nAnother issue that could change a lot of this logic would be if we start to support by-name parameters at call sites, since we could no longer assume that the argument and parameter lists align one-to-one (with the argument list possibly being shorter). Any work to add more flexible argument passing conventions would need to build a suitable structure to map from arguments to parameters, or vice-versa.","distinct":false,"url":"https://api.github.com/repos/jsmall-nvidia/slang/commits/b4c4dc92c0b21f0253c4ccf34107638f7c36b62e"},{"sha":"8c50f9f2d51ffd77903b742993dae6a663b38286","author":{"name":"Tim Foley","email":"4483be28d7b118b23be41d8cd38a24491f0ef11e@users.noreply.github.com"},"message":"Make IR-based output code cleaner (#458)\n\nThe big change here is that rather than trying to reproduce the exact line number and indentation of names as they appeared in the original code (which had been appropriate for the AST-to-AST translation strategy), we now emit code from the IR using a simple \"pretty-printing\" strategy, where indentation is determined by nesting.\r\n\r\nAlong the way I deleted a bunch of dead code in `emit.cpp` that was handling emit from AST declarations/statements/expressions. I probably should have pulled that out into its own change, but doing that now would be tricky.\r\n\r\nThis change also makes it so that we do *not* emit `#line` directives by default. Asking for `#line` directives in the output will probably become part of a Slang \"debug mode\" that tries to make the output code suitable for step-through debugging.","distinct":false,"url":"https://api.github.com/repos/jsmall-nvidia/slang/commits/8c50f9f2d51ffd77903b742993dae6a663b38286"},{"sha":"b61371d06c3ac18d1df6798b8042d4252485d935","author":{"name":"Tim Foley","email":"4483be28d7b118b23be41d8cd38a24491f0ef11e@users.noreply.github.com"},"message":"Change uses of \"spire\" to \"slang\" (#461)\n\nFixes #350\r\n\r\nWhen the Slang project forked off from the Spire research effort, we renamed things as we went, but many cases seem to have slipped through the cracks.\r\n\r\nThe two biggest diffs here are:\r\n\r\n- The `hello` example program was incorrectly talking about what was in the shader file (Slang no longer supports the \"module\" or \"pipeline\" constructs from Spire), and so it wasn't just a simple rename.\r\n\r\n- The files under `tests/bindings` were mistakenly using `__SPIRE__` as a preprocessor guard, which means that they weren't actually testing what they meant to. Luckily, it looks like the relevant functionality didn't regress while these tests were unintentionally deactivated.","distinct":false,"url":"https://api.github.com/repos/jsmall-nvidia/slang/commits/b61371d06c3ac18d1df6798b8042d4252485d935"},{"sha":"87c50cf1644454cdc9e7f6d1262bee29bfc86e80","author":{"name":"Tim Foley","email":"4483be28d7b118b23be41d8cd38a24491f0ef11e@users.noreply.github.com"},"message":"Avoid crash when bad argument given to [instance(...)] attribute (#464)\n\nFixes #463\r\n\r\nSome of the attributes were failing to check for a `null` result from `checkConstantIntVal`, and so they crashed when a bad expression was used in an attribute. The particular way this had been triggered was that a user put an HLSL geometry shader in the same file with other code, using an entry point like:\r\n\r\n```hlsl\r\n[instance(COUNT)]\r\nvoid myGeometryShader(...) {...}\r\n```\r\n\r\nThey then defined `COUNT` as a preprocessor macro when compiling using the GS, but left it undefined otherwise. The result was that the argument to the `instance` attribute would fail to type check, and thus wouldn't count as a constant integer value, so that `checkConstantIntVal` returns `null` and results in the crash.\r\n\r\nThe workaround for the user is to always define `COUNT`, even when not compiling the GS.\r\n\r\nThe fix in the compiler is to guard against `null` in these cases and bail out of attribute checking. I also implemented logic so that `CheckIntegerConstantExpression` (which is invoked by `checkConstantIntVal`) will not produce an additional error message if the underlying expression failed to type check. In this casem the user will get an `undefined identifier: COUNT` error message, and we don't need to waste their time by also telling them that this isn't a compile-time constant expression.","distinct":false,"url":"https://api.github.com/repos/jsmall-nvidia/slang/commits/87c50cf1644454cdc9e7f6d1262bee29bfc86e80"},{"sha":"bd66d4f90086eeff339f076f8cedfbf78e1989b6","author":{"name":"Tim Foley","email":"4483be28d7b118b23be41d8cd38a24491f0ef11e@users.noreply.github.com"},"message":"Fix several issues discovered by Falcor (#467)\n\nFixes #466\r\n\r\nMost of these are Vulkan-related regressions.\r\n\r\n* Kludge the definition of `GroupMemoryBarrierWithGroupSync()` for GLSL so that it works around parentheses that the emit logic now introduces.\r\n\r\n* Don't emit `static` for global constants when targetting GLSL\r\n\r\n* Emit the `flat` modifier for varying input/output with integer type, when targetting GLSL\r\n\r\n* Avoid checking parameter default-value expressions more than once, because this can crash when the checking introduces syntax that is not expected to appear in the input AST","distinct":false,"url":"https://api.github.com/repos/jsmall-nvidia/slang/commits/bd66d4f90086eeff339f076f8cedfbf78e1989b6"},{"sha":"5a0273848aa4b854bb3c99a81701b044a8929bf8","author":{"name":"Tim Foley","email":"4483be28d7b118b23be41d8cd38a24491f0ef11e@users.noreply.github.com"},"message":"Update to top-of-tree glslang (2018-04-02). (#470)\n\nThis is an attempt to alleviate some driver crashes caused by invalid SPIR-V. Because Slang drives `glslang` with GLSL source code, any invalid output is likely due to `glslang` bugs.\r\n\r\nI chose top-of-tree for `glslang` because it wasn't clear what their release process is. Hopefully we can go another year without having to update this dependency.\r\n\r\nThe build setup we use for `glslang` had to change to account for one more `#define` that the code expects to have passed in externally.","distinct":false,"url":"https://api.github.com/repos/jsmall-nvidia/slang/commits/5a0273848aa4b854bb3c99a81701b044a8929bf8"},{"sha":"38d5ef4764e9271ce2360f42b0759a236cddd9fe","author":{"name":"jsmall-nvidia","email":"9bca19b6fb246b400fbd8bc3e81fbfcf8e88f975@nvidia.com"},"message":"Feature/dx12 (#469)\n\n* Fix signed/unsigned comparison warning.\r\n\r\n* Split out d3d functions that will work across dx11 and 12.\r\n\r\n* Improve slang-test/README.md around command line options.\r\n\r\n* Make Guid comparison honor alignment for comparisons, such that mechanism work on architectures that can only do aligned accesses.\r\n\r\n* Initial setup of D3D12 Renderer, with presentFrame and clearFrame.\r\n\r\n* More support for D3D12\r\n\r\n* Added FreeList\r\n* Added D3D12CircularResourceHeap\r\n* First attempt at createBuffer\r\n\r\n* First pass at map/unmap.\r\n\r\n* First pass binding vertex/constant buffers, and setting up InputLayout. Note that memory is not kept in scope on binding yet.\r\n\r\n* First pass of D3DDescriptorHeap\r\n\r\n* Small tidy up in render-d3d11. Added D3DDescriptorHeap to project.\r\n\r\n* First pass at D3D12 bind state.\r\n\r\n* Fix typos in D3D12Resource\r\n\r\n* Tidy up Dx11 render binding a little to match more with Dx12 style.\r\n\r\n* First pass at Dx12 BindingState\r\n\r\n* Handling of the command list d3d12. Support for submitGpuWork and waitForGpu.\r\n\r\n* First attempt at Dx12 capture of backbuffer to file.\r\n\r\n* First attempt at D3D12 binding for graphics.\r\n\r\n* D3D12 setup viewport etc - does now render triangle in render0.hlsl.\r\n\r\n* First pass at support for compute on D3D12Renderer\r\n\r\n* Use spaces over tabs in D3DUtil\r\n\r\n* Tabs to spaces in D3D12DescriptorHeap\r\n\r\n* Convert tab->spaces on render-d3d12.cpp","distinct":true,"url":"https://api.github.com/repos/jsmall-nvidia/slang/commits/38d5ef4764e9271ce2360f42b0759a236cddd9fe"},{"sha":"499e2586cba2a7ba2a703b90c459b24620e351ee","author":{"name":"Tim Foley","email":"4483be28d7b118b23be41d8cd38a24491f0ef11e@users.noreply.github.com"},"message":"Implement \"operator comma\" in IR codegen (#472)\n\nFixes #471","distinct":true,"url":"https://api.github.com/repos/jsmall-nvidia/slang/commits/499e2586cba2a7ba2a703b90c459b24620e351ee"}]}
{"actor":{"display_login":"jsmall-nvidia"}}