https://github.com/shader-slang/slang
- HEAD
- refs/heads/csyonghe-patch-1
- refs/heads/glsl-intrinsic-functional-test
- refs/heads/master
- refs/heads/release-debug
- refs/heads/swoods-nv-patch-1
- refs/tags/''
- refs/tags/v''
- refs/tags/v0.12.19
- refs/tags/v0.12.26
- refs/tags/v0.12.27
- refs/tags/v0.12.28
- refs/tags/v0.12.29
- refs/tags/v0.13.4
- refs/tags/v0.13.5
- refs/tags/v0.13.6
- refs/tags/v0.13.6.1
- refs/tags/v0.24.39
- refs/tags/v0.24.40
- refs/tags/v0.24.41
- refs/tags/v0.24.42
- refs/tags/v0.24.48
- refs/tags/v0.24.49
- refs/tags/v0.24.50
- refs/tags/v0.24.52
- refs/tags/v0.8.3
- refs/tags/v0.8.4
- refs/tags/v0.8.5
- refs/tags/v0.8.5-rc
- refs/tags/v0.8.6
- refs/tags/v0.8.6-rc
- refs/tags/v0.8.7
- refs/tags/v0.8.8
- refs/tags/v2023.5.5
- refs/tags/v2024.1.10
- refs/tags/v2024.1.11
- refs/tags/v2024.1.13
- refs/tags/v2024.1.15
- refs/tags/v2024.1.16
- refs/tags/v2024.1.19
- refs/tags/v2024.1.27
- refs/tags/v2024.1.28
- refs/tags/v2024.1.29
- refs/tags/v2024.1.30
- refs/tags/v2024.1.7
- refs/tags/v2024.1.9
- refs/tags/v2024.10.1-draft
- refs/tags/v2024.9
- refs/tags/v2024.9.1
- v0.18.22
- v2024.9.2
- v2024.10
- v2024.1.8
- v2024.1.6
- v2024.1.5
- v2024.1.4
- v2024.1.34
- v2024.1.33
- v2024.1.32
- v2024.1.31
- v2024.1.3
- v2024.1.26
- v2024.1.25
- v2024.1.24
- v2024.1.23
- v2024.1.22
- v2024.1.21.1
- v2024.1.21
- v2024.1.20
- v2024.1.2
- v2024.1.18
- v2024.1.17
- v2024.1.14
- v2024.1.12
- v2024.1.1
- v2024.1.0
- v2024.0.9
- v2024.0.8
- v2024.0.7
- v2024.0.6
- v2024.0.5
- v2024.0.4
- v2024.0.3
- v2024.0.2
- v2024.0.15
- v2024.0.14
- v2024.0.13
- v2024.0.12
- v2024.0.11
- v2024.0.10
- v2024.0.1
- v2024.0.0
- v2023.5.8
- v2023.5.7
- v2023.5.6
- v2023.5.4
- v2023.5.3
- v2023.5.2
- v2023.5.1
- v2023.5.0
- v2023.4.9
- v2023.4.8
- v2023.4.7
- v2023.4.6
- v2023.4.5
- v2023.4.4
- v2023.4.3
- v2023.4.2
- v2023.4.10
- v2023.4.1
- v2023.4.0
- v2023.3.9
- v2023.3.8
- v2023.3.7
- v2023.3.6
- v2023.3.5
- v2023.3.4
- v2023.3.3
- v2023.3.20
- v2023.3.2
- v2023.3.19
- v2023.3.18
- v2023.3.17
- v2023.3.16
- v2023.3.15
- v2023.3.14
- v2023.3.13
- v2023.3.12
- v2023.3.11
- v2023.3.10
- v2023.3.1
- v2023.3.0
- v2023.2.1
- v2023.2.0
- v2023.1.1
- v2023.1.0
- v2023.0.6
- v2023.0.5
- v2023.0.4
- v2023.0.3
- v2023.0.2
- v2023.0.1
- v2023.0.0
- v0.9.9
- v0.9.8
- v0.9.7
- v0.9.6
- v0.9.5
- v0.9.4
- v0.9.3
- v0.9.2
- v0.9.15
- v0.9.14
- v0.9.13
- v0.9.12
- v0.9.11
- v0.9.10
- v0.9.1
- v0.9.0
- v0.8.9
- v0.8.2
- v0.8.13
- v0.8.12
- v0.8.11
- v0.8.10
- v0.8.1
- v0.8.0
- v0.7.9
- v0.7.8
- v0.7.7
- v0.7.6
- v0.7.5
- v0.7.4
- v0.7.3
- v0.7.2
- v0.7.10
- v0.7.1
- v0.7.0
- v0.6.9
- v0.6.8
- v0.6.7
- v0.6.6
- v0.6.5
- v0.6.4
- v0.6.3
- v0.6.2
- v0.6.1
- v0.6.0
- v0.5.6
- v0.5.5
- v0.5.4
- v0.5.3
- v0.5.2
- v0.5.1
- v0.5.0
- v0.4.2
- v0.4.1
- v0.4.0
- v0.3.2
- v0.3.1
- v0.3.0
- v0.28.3
- v0.28.2
- v0.28.1
- v0.28.0
- v0.27.9
- v0.27.8
- v0.27.7
- v0.27.6
- v0.27.5
- v0.27.4
- v0.27.3
- v0.27.21
- v0.27.20
- v0.27.2
- v0.27.19
- v0.27.18
- v0.27.17
- v0.27.16
- v0.27.15
- v0.27.14
- v0.27.13
- v0.27.12
- v0.27.11
- v0.27.10
- v0.27.1
- v0.27.0
- v0.26.0
- v0.25.5
- v0.25.4
- v0.25.3
- v0.25.2
- v0.25.1
- v0.25.0
- v0.24.9
- v0.24.8
- v0.24.7
- v0.24.6
- v0.24.54
- v0.24.53
- v0.24.51
- v0.24.5
- v0.24.47
- v0.24.46
- v0.24.45
- v0.24.44
- v0.24.43
- v0.24.4-fix
- v0.24.4
- v0.24.38
- v0.24.37
- v0.24.36
- v0.24.35
- v0.24.34
- v0.24.33
- v0.24.32
- v0.24.31
- v0.24.30
- v0.24.3
- v0.24.29
- v0.24.28
- v0.24.27.1
- v0.24.27
- v0.24.26.2
- v0.24.26
- v0.24.25
- v0.24.24
- v0.24.23
- v0.24.22
- v0.24.21
- v0.24.20
- v0.24.2
- v0.24.19
- v0.24.18
- v0.24.17
- v0.24.16
- v0.24.15
- v0.24.14
- v0.24.13
- v0.24.12
- v0.24.11
- v0.24.10
- v0.24.1
- v0.24.0
- v0.23.9
- v0.23.8
- v0.23.7
- v0.23.6
- v0.23.5
- v0.23.4
- v0.23.3
- v0.23.2
- v0.23.14
- v0.23.13
- v0.23.12
- v0.23.11
- v0.23.10
- v0.23.1
- v0.23.0
- v0.22.0
- v0.21.2
- v0.21.1
- v0.21.0
- v0.20.1
- v0.20.0
- v0.2.0
- v0.19.9
- v0.19.8
- v0.19.7
- v0.19.6
- v0.19.5
- v0.19.4
- v0.19.3
- v0.19.26
- v0.19.25
- v0.19.24
- v0.19.23
- v0.19.22
- v0.19.21
- v0.19.20
- v0.19.2.1
- v0.19.2
- v0.19.19
- v0.19.18
- v0.19.17
- v0.19.16
- v0.19.15
- v0.19.14
- v0.19.13
- v0.19.12
- v0.19.11
- v0.19.10
- v0.19.1
- v0.19.0
- v0.18.9
- v0.18.8
- v0.18.7
- v0.18.6
- v0.18.5
- v0.18.4-pre
- v0.18.4
- v0.18.3
- v0.18.25
- v0.18.24
- v0.18.23
- v0.18.21
- v0.18.20
- v0.18.2
- v0.18.19
- v0.18.18
- v0.18.17
- v0.18.16
- v0.18.15
- v0.18.14
- v0.18.13
- v0.18.12
- v0.18.11
- v0.18.10
- v0.18.1
- v0.18.0
- v0.17.7
- v0.17.6
- v0.17.5
- v0.17.4
- v0.17.3
- v0.17.2
- v0.17.1
- v0.17.0
- v0.16.9
- v0.16.8
- v0.16.7
- v0.16.6
- v0.16.5
- v0.16.4
- v0.16.3
- v0.16.2
- v0.16.14
- v0.16.13
- v0.16.12
- v0.16.11
- v0.16.10
- v0.16.1
- v0.16.0
- v0.15.9
- v0.15.8
- v0.15.7
- v0.15.6
- v0.15.5
- v0.15.4
- v0.15.3
- v0.15.2
- v0.15.13
- v0.15.12
- v0.15.11.2
- v0.15.11.1
- v0.15.11
- v0.15.10
- v0.15.1
- v0.15.0
- v0.14.3
- v0.14.2
- v0.14.1
- v0.14.0
- v0.13.9
- v0.13.8
- v0.13.7
- v0.13.3
- v0.13.2
- v0.13.13
- v0.13.12
- v0.13.11
- v0.13.10
- v0.13.1
- v0.13.0
- v0.12.9
- v0.12.8
- v0.12.7
- v0.12.6
- v0.12.5
- v0.12.4
- v0.12.30
- v0.12.3
- v0.12.25
- v0.12.24
- v0.12.23
- v0.12.22
- v0.12.21
- v0.12.20
- v0.12.2
- v0.12.18
- v0.12.17
- v0.12.16
- v0.12.15
- v0.12.14
- v0.12.13
- v0.12.12
- v0.12.11
- v0.12.10
- v0.12.1
- v0.12.0
- v0.11.9
- v0.11.8
- v0.11.7
- v0.11.6
- v0.11.5
- v0.11.4
- v0.11.3
- v0.11.23
- v0.11.22
- v0.11.21
- v0.11.20
- v0.11.2
- v0.11.19
- v0.11.18
- v0.11.17
- v0.11.16
- v0.11.15
- v0.11.14
- v0.11.13
- v0.11.12
- v0.11.11
- v0.11.10
- v0.11.1
- v0.11.0
- v0.10.9
- v0.10.8
- v0.10.7
- v0.10.6
- v0.10.5
- v0.10.4
- v0.10.36
- v0.10.35
- v0.10.34
- v0.10.33
- v0.10.32
- v0.10.31
- v0.10.30
- v0.10.3
- v0.10.29
- v0.10.28-rc3
- v0.10.28-rc2
- v0.10.28-rc1
- v0.10.27
- v0.10.26
- v0.10.25
- v0.10.24
- v0.10.23
- v0.10.22
- v0.10.21
- v0.10.20
- v0.10.2
- v0.10.19
- v0.10.18
- v0.10.17
- v0.10.16
- v0.10.15
- v0.10.14
- v0.10.13
- v0.10.12
- v0.10.11
- v0.10.10
- v0.10.1
- v0.10.0
- v0.1.0
- v-test.22.6.15.1
- v-test.22.6.15.0
- v-test-220616-1
- v-test-220615-4
- v-test-220615-3
- v-test-220615-2
Take a new snapshot of a software origin
If the archived software origin currently browsed is not synchronized with its upstream version (for instance when new commits have been issued), you can explicitly request Software Heritage to take a new snapshot of it.
Use the form below to proceed. Once a request has been submitted and accepted, it will be processed as soon as possible. You can then check its processing state by visiting this dedicated page.![swh spinner](/static/img/swh-spinner.gif)
Processing "take a new snapshot" request ...
Permalinks
To reference or cite the objects present in the Software Heritage archive, permalinks based on SoftWare Hash IDentifiers (SWHIDs) must be used.
Select below a type of object currently browsed in order to display its associated SWHID and permalink.
Revision | Author | Date | Message | Commit Date |
---|---|---|---|---|
e59aee1 | Yong He | 17 February 2021, 23:09:09 UTC | Add `SampleGrad` overload for lod clamp. (#1711) * Add `SampleGrad` overload for lod clamp. * Fix gfx to run the test on vulkan. * Whitespace change to trigger CI build * remove presentFrame call in render-test Co-authored-by: Yong He <yhe@nvidia.com> Co-authored-by: Tim Foley <tfoleyNV@users.noreply.github.com> | 17 February 2021, 23:09:09 UTC |
39975b2 | Tim Foley | 16 February 2021, 22:03:39 UTC | Fixes to get shader-object example working on CUDA (#1708) The purpose of these changes is to make the `shader-object` example work correctly on CUDA. Originally I had tried to add changes to the "flat" reflection information so that it introduced descriptor ranges to match the binding ranges it added for interface/existential-type fields. This approach helped the CUDA code that was using that information to try and compute uniform offsets for those fields, but it broke most of the other renderer back-ends. Instead, I removed the relevant asserts from `CUDAShaderObject::setObject()`. Note taht there are leftover changes from my edits to the flat reflection information, around how it handles "leaf" fields that consume multiple resource kinds. I believe that those changes are, on balance, "more correct" now than they were before, so I decided to leave them in. The other major fix here is to specialize the `CUDAShaderObject::setObject()` logic to handle the case of setting a shader object for a parameter that has interface type instead of a constant-buffer or parameter block. Mostly I just copy bytes from the child object into the parent object. There are a few caveats, though: * I am not writing the RTTI or witness-table information, so dynamic dispatch won't work. * I am assuming a hard-coded offset of 16 bytes for the any-value, which will work for now but is a bit too "magical" and might also break once we support conjunctions of interfaces with dynamic dispatch * I am assuming that the child value to be writen into the field will "fit" into the any-value area. We need some way to determine whether or not things fit dynamically (ideally using the reflection data), and adapt accordingly. * I had to add another method on the base CUDA shader object type to handle setting data using a device-memory pointr instead of a host-memory pointer * There's not a lot we can do about it, but in the case of assigning an ordinary `CUDAShaderObject` into an interface-type field of a `CUDAEntryPointShaderObject` we end up needing to perform a device->host memory copy, because the bytes of the value will have already been written to GPU memory, but need to be in GPU memory for the dispatch call. * The implementation I'm using here basically assumes that the child shader object must have been finalized before it gets plugged into the parent shader object. We haven't yet made a policy decision about that bit. | 16 February 2021, 22:03:39 UTC |
e474c4e | Tim Foley | 16 February 2021, 19:48:21 UTC | Add an accessor for IRInst opcode (#1707) * Add an accessor for IRInst opcode This main changing is renaming `IRInst::op` over to `IRInst::m_op` and then adds an accessor `IRInst::getOp()` to read it. The rest of the changes are just changing use sites to `getOp` (or to `m_op` in the limited cases where we write to it). This work is in anticipation of a future change that might need to store an extra bit in the same field as the opcode. It seemed better to do this massive refactoring as a separate PR. * fixup | 16 February 2021, 19:48:21 UTC |
5777545 | Yong He | 12 February 2021, 23:01:45 UTC | Add associated type and generic value parameter doc section (#1706) * Add associated type and generic value parameter doc section * Typos and corrections. | 12 February 2021, 23:01:45 UTC |
e2096cf | Tim Foley | 12 February 2021, 21:48:11 UTC | Initial support for DXR payload access qualifiers (#1705) This change adds initial support for a feature being proposed for inclusion in dxc: https://github.com/microsoft/DirectXShaderCompiler/pull/3171. The main features are: * A `[payload]` attribute that indicates which `struct` types are intended to be used as payloads. Consistent use of this attribute should mean that an application no longer needs to manually specify a maximum payload size when creating a ray-tracing pipeline. * `read(...)` and `write(...)` qualifiers which can be attached to fields of `struct` types (usually `[payload]`-attributed types) to indicate which ray tracing pipeline stages are allowed read/write access to that part of the payload. Use of these qualifiers should allow an implementation to optimize storage of ray payload elements across RT pipeline stages. The work in this change just adds basic parsing for these features, translation to matching IR decorations, and then emission of HLSL text based on those decorations. Notable gaps in this first change include: * No work is currently being done to validate access to ray payloads in RT entry points based on these qualifiers. * The stage names in `read(...)` and `write(...)` are not being validated, and are being stored in the IR as text. These should probably use the `Stage` enumeration in some fashion, but we would need to have a way to encode the additional `caller` pseudo-stage that the feature uses. * No work is currently being done to adjust or react to the chosen shader model when emitting HLSL code. We should *either* have these attributes force a switch to a higher shader model, *or* skip emission of these attributes if the chosen shader model / profile does not imply support for them. * No tests are currently included for this work, because tests would rely on using a custom `dxcompiler.dll` build with the new feature supported. | 12 February 2021, 21:48:11 UTC |
0dea127 | Yong He | 12 February 2021, 20:54:48 UTC | First part of interfaces and generics doc. (#1704) Co-authored-by: Tim Foley <tfoleyNV@users.noreply.github.com> | 12 February 2021, 20:54:48 UTC |
0befc84 | Tim Foley | 12 February 2021, 20:53:56 UTC | Further documentation work (#1703) * Move around the conventional/convenience features chapters * Add a first draft of a section on compilation using `slangc` and the COM-lite API Co-authored-by: Yong He <yonghe@outlook.com> | 12 February 2021, 20:53:56 UTC |
a2401a6 | Yong He | 12 February 2021, 20:20:17 UTC | Support `bit_cast` between complex types. (#1702) * Support `bit_cast` between complex types. * Fix vs project file * Fix clang build error * fix * fix * Fix * FIx * Fix * Fix * Fix * Fix * Fix linux compile error Co-authored-by: Tim Foley <tfoleyNV@users.noreply.github.com> | 12 February 2021, 20:20:17 UTC |
369279e | jsmall-nvidia | 12 February 2021, 19:31:56 UTC | Diagnostic location highlighting (#1700) * #include an absolute path didn't work - because paths were taken to always be relative. * WIP: First pass in supporting output of line error information. * Add support for lexing to better be able to indicate SourceLocation information. * Fix lexer usage in DiagnosticSink in C++ extractor. * Update diagnostics tests to have line location info. * Fixed test expected output that now have source location information in them. * Better handling of tab. * Fix test expected results for tabbing change. * DiagnosticLexer -> DiagnosticSink::SourceLocationLexer Added line continuation tests. * Fix typo. * Added String::appendRepeatedChar * Change to rerun tests. Co-authored-by: Tim Foley <tfoleyNV@users.noreply.github.com> | 12 February 2021, 19:31:56 UTC |
cd79bfb | Yong He | 11 February 2021, 18:09:20 UTC | Add convenience features chapter in user-guide doc (#1699) * Fix getting started doc * Add convenience features chapter in user-guide doc Co-authored-by: Tim Foley <tfoleyNV@users.noreply.github.com> | 11 February 2021, 18:09:20 UTC |
e1b1ce3 | Tim Foley | 11 February 2021, 00:35:52 UTC | Fix a bug in IR lowering (#1701) The underlying problem here is that our `SharedIRBuilder` (which currently owns the "global" value-numbering map) has a subtle invariant ("subtle" in the sense of "dangerous and bad"). The value-numbering map stores `IRInst`s for things like constants and types, and if those instructions end up getting modified or deleted (deleting an instruction currently runs its destructor but does not free the pool-allocated memory), then it is possible for the computed hash code for an instruction to no longer match what it was when it was inserted. The trigger in this case was a use of the `IRInst::removeAndDeallocate()` operation inside of the AST-to-IR lowering pass, which uses a single `SharedIRBuilder`. If that `removeAndDeallocate()` happens to apply to a value in the value-numbering map, then it risks breaking the next time the map gets rehashed. The short-term fix here is simple: never try to delete an instruction during IR lowering, even if it is known to be unused. Instead, we can rely on the subsequent DCE pass to eliminate the instruction. A longer-term fix here would involve fixing our entire strategy around value numbering. We know we need to do that, but that would be a big enough change that it couldn't be pursued as part of a simple bug fix like this. | 11 February 2021, 00:35:52 UTC |
8750a7c | Tim Foley | 10 February 2021, 02:16:28 UTC | Add more to User's Guide (#1698) This change adds a first draft of an Introduction chapter, along with a chapter about the "conventional" features of Slang (when compared to HLSL, GLSL, and C/C++). | 10 February 2021, 02:16:28 UTC |
03f6389 | Yong He | 09 February 2021, 16:40:27 UTC | Add getting started documentation (#1697) * Add getting started documentation * wording * wording | 09 February 2021, 16:40:27 UTC |
53ff724 | jsmall-nvidia | 08 February 2021, 22:53:02 UTC | Hotfix/doc typo lexical (#1696) * #include an absolute path didn't work - because paths were taken to always be relative. * Fix typo | 08 February 2021, 22:53:02 UTC |
10a55d8 | jsmall-nvidia | 08 February 2021, 22:49:45 UTC | DX12 & NVAPI fixes (#1695) * #include an absolute path didn't work - because paths were taken to always be relative. * Fix bugs with m_features on Dx12 and gl. Fix issue about GFX_NVAPI availability. * Fix handling of SLANG_E_NOT_AVAILABLE on renderer startup. * Clarify comment. * Improve comment. | 08 February 2021, 22:49:45 UTC |
891791e | jsmall-nvidia | 08 February 2021, 21:29:31 UTC | Copy SourceLoc when inlining (#1692) * #include an absolute path didn't work - because paths were taken to always be relative. * Copy source loc information when inlining. | 08 February 2021, 21:29:31 UTC |
df7548e | Yong He | 05 February 2021, 22:36:07 UTC | Shader-Object example (#1694) | 05 February 2021, 22:36:07 UTC |
5fbaccf | jsmall-nvidia | 05 February 2021, 19:59:46 UTC | Typo in renderer name for DX12 (#1693) * #include an absolute path didn't work - because paths were taken to always be relative. * Typo for renderer name for DX12. | 05 February 2021, 19:59:46 UTC |
adb1131 | Tim Foley | 05 February 2021, 17:01:36 UTC | Initial implementation of interface conjunctions (#1691) The basic feature here is the ability to use the `&` operator to produce the conjunction/intersection of two interfaces. That is, you can have interfaces: interface IFirst { int getFirst(); } interface ISecond { int getSecoond(); } and if you need a generic function where the type parameter `T` must conform to *both* of these interfaces, you express that by constraining the parameter to the intersection of the interfaces: void someFunction<T : IFirst & ISecond>(T value) { ... } Without this feature, the main alternative an application would have is to define an intermediate interface, like: interface IBoth : IFirst, ISecond {} Forcing users to deal with an intermediate interface creates more work for type authors (they need to remember to inherit from the right combined interface(s)), or for `extension` authors (when you add `ISecond` to a type that used to just support `IFirst`, you had better also add `IBoth`). In the worst case, a family of N related "leaf" interfaces would give rise to an exponential number of intermediate interfaces to represnt the possible combinations. A conjunction like `IFirst & ISecond` is officially its own type, and can be used to declare a type alias: typealias IBoth = IFirst & ISecond; This change only includes the first pass of work on this feature, so there are several caveats to be aware of: * Using a conjunction as part of an inheritance clause is not yet supported (e.g., `struct X : IFirst & ISecond`). This is true even if the conjunction was introduced by an intermediate `typealias` * The `&` syntax introduced here is only parsed in places where only a type (not an expression) is possible. This means you cannot do things like cast to a conjunction with `(IFirst & ISecond)(someValue)`. * This work *should* apply to conjunctions of more than two interfaces (like `IA & IB & IC`) but that has not yet been tested * In the long run it may be sensible to allow conjunctions that use concrete types, but we really ought to have the semantic checking logic rule that out for now. * During testing, I encountered compiler crashes when trying to use this feature together with `property` declarations. Further investigation and debugging is called for. * The handling of conjunction types is currently incomplete, in that there are many equivalences the compiler does not yet understand. For example, it is clear that `IA & IB` is equivalent to `IB & IA`, but the compiler currently does not understand this and will treat them as different types. A deeper implementation approach is called for. * Conjunctions are currently only supported for generic type parameter constraints, when performing full specialization. Use of conjunctions for existential-type value parameters or with dynamic dispatch is not yet supported. | 05 February 2021, 17:01:36 UTC |
fb05343 | jsmall-nvidia | 04 February 2021, 23:45:50 UTC | Fix line offset problem (#1690) * #include an absolute path didn't work - because paths were taken to always be relative. * WIP diagnostics for line number output. * Small param naming change * Use x macro for pass through compile human name lookup/getting. * WIP on parsing downstream compiler output. * Split out parsing into ParseDiagnosticUtil. Added test result of single line. * Dump out the std output on fail to parse diagnostics. * Change test type for syntax-error-intrinsic.slang be TEST not TEST_DIAGNOSTIC * Use Index for StringUtil. * WIP: First pass support for parsing Slang diagnostics. * WIP Testing comparing with ParseDiagnosticUtil with previous ad-hoc mechanism. * Use the new parsing mechanism for diagnostic comparisons. * Fix layout on GLSL, doesn't have CR so runs into main. * Split out switch on outputting intrinsic 'specials'. Output code around intrinsic as emit - so that we get the appropriate indenting (and potentially other benefits). * Improvements to diagnostics parsing. Better error handling, and fallback handling. Added ability to parse downstream compilers without a prefix. Added ability to parse Slang with a prefix. * DownstreamDiagnostic::Type -> Severity and related fixes. * Small fixes around moving from DownstreamDiagnostic::Type -> Severity * Fix handling of 'special intrinsic' expansion * Split out the handling of intrinsic expansion into it's own type and files. * Fixes to reading expected output - for SimpleLine test. * Test using += to check #line output. * A test around += and return. * Small comment fixes. Co-authored-by: Tim Foley <tfoleyNV@users.noreply.github.com> | 04 February 2021, 23:45:50 UTC |
c40f10b | Yong He | 04 February 2021, 21:50:51 UTC | [gfx] Shader-object driven shader compilation. (#1688) | 04 February 2021, 21:50:51 UTC |
7f266f1 | jsmall-nvidia | 04 February 2021, 19:23:32 UTC | DownstreamDiagnostic::Type -> Severity (#1687) * #include an absolute path didn't work - because paths were taken to always be relative. * WIP diagnostics for line number output. * Small param naming change * Use x macro for pass through compile human name lookup/getting. * WIP on parsing downstream compiler output. * Split out parsing into ParseDiagnosticUtil. Added test result of single line. * Dump out the std output on fail to parse diagnostics. * Change test type for syntax-error-intrinsic.slang be TEST not TEST_DIAGNOSTIC * Use Index for StringUtil. * WIP: First pass support for parsing Slang diagnostics. * WIP Testing comparing with ParseDiagnosticUtil with previous ad-hoc mechanism. * Use the new parsing mechanism for diagnostic comparisons. * Improvements to diagnostics parsing. Better error handling, and fallback handling. Added ability to parse downstream compilers without a prefix. Added ability to parse Slang with a prefix. * DownstreamDiagnostic::Type -> Severity and related fixes. * Small fixes around moving from DownstreamDiagnostic::Type -> Severity * Small comment fixes. Co-authored-by: Tim Foley <tfoleyNV@users.noreply.github.com> | 04 February 2021, 19:23:32 UTC |
ef283b8 | Tim Foley | 04 February 2021, 19:15:46 UTC | Change how function-scope static variables lower to IR (#1686) This change pertains to `static` variables in function scope (including things like methods, initializers, property accessors, etc.). Note that it does *not* have anything to do with global-scope `static` variables or with `static const` variables (whether inside a function or not). The old code generation strategy had a lot of "clever" code to deal with the problem of a `static` variable inside a generic function (or inside a function inside a generic type, etc.). Basically, if you had input code like: int myFunc<T>(int newVal) { static int state = 0; int result = state; state = newVal; return result; } The language semantics are that `myFunc<float3>` should have a different `state` variable than `myFunc<int2>`. The way that the existing codegen handled that was to generate the `state` variable into its own dedicated `IRGeneric`. Something like: generic myFunc_state<T0> { global_var g_ptr : int*; return g_ptr; } generic myFunc<T1> { func f(int newVal) { let result : int = load(state<T>); store(state<T1>, newVal); return result; } } The catch there is that you end up needing to generate an entire second `IRGeneric`, and then references to `state` need to explicitly use `specialize` to instantiate that generic using the same parameters as `myFunc` was passed (note how `T0` and `T1` are distinct IR generic parameters, despite both representing `T` here). Things get even more complicated when you consider function-`static` variables with initialization logic, since we need to be sure we only perform that initialization once, but the initialization could refer to arguments of the outer function, and thus needs to be done inside the function body. To handle that case we emit an additional `bool` global if a function-`static` variable has an initializer, and that `bool` gets wrapped up in yet another generic. That whole approach seems silly in retrospect, and a much simpler solution is possible: just emit the function-`static` variable immediately before the IR function it pertains to, which means it will be nested under the *same* IR generic if there is one (and at module scope if there isn't). The result is something like: generic myFunc<T1> { global_var state_ptr : int*; func f(int newVal) { let result : int = load(state_ptr); store(state_ptr, newVal); return result; } } This change implements that simplification, and all the same tests pass (including whatever tests we had for function-`static` variables). | 04 February 2021, 19:15:46 UTC |
4c66c17 | jsmall-nvidia | 03 February 2021, 21:31:58 UTC | Diagnostic comparison using parsing (#1683) * #include an absolute path didn't work - because paths were taken to always be relative. * WIP diagnostics for line number output. * Small param naming change * Use x macro for pass through compile human name lookup/getting. * WIP on parsing downstream compiler output. * Split out parsing into ParseDiagnosticUtil. Added test result of single line. * Dump out the std output on fail to parse diagnostics. * Change test type for syntax-error-intrinsic.slang be TEST not TEST_DIAGNOSTIC * Use Index for StringUtil. * WIP: First pass support for parsing Slang diagnostics. * WIP Testing comparing with ParseDiagnosticUtil with previous ad-hoc mechanism. * Use the new parsing mechanism for diagnostic comparisons. * Improvements to diagnostics parsing. Better error handling, and fallback handling. Added ability to parse downstream compilers without a prefix. Added ability to parse Slang with a prefix. | 03 February 2021, 21:31:58 UTC |
a1d543d | Tim Foley | 02 February 2021, 23:45:19 UTC | Remove GlobalGenericParamSubstitution (#1684) The `GlobalGenericParamSubsitution` class used to be used to represent the mapping of global-scope generic parameters to their concrete arguments, so that we could make use of those concrete arguments for things like layout. That representation caused a lot of pain for other parts of the compiler, though, because everything that dealt with `Substitution`s needed to account for the possibility of global-generic-param subsitutions even if they logically could not occur in most parts of the compiler. We have since moved to a model where the values for global-scope generic parameters are stored in a single explicit global structure that is used by both layout computation and IR lowering. There is no actual code that construct `GlobalGenericParamSubstitution`s from scratch any more, so all of the support code for them was actually unused. This change removes all the unused code, and shows that the tests still pass without it (even the tests that use global-scope generic parameters). | 02 February 2021, 23:45:19 UTC |
17d2b24 | jsmall-nvidia | 02 February 2021, 22:45:56 UTC | Downstream compiler line number test (#1682) * #include an absolute path didn't work - because paths were taken to always be relative. * WIP diagnostics for line number output. * Small param naming change * Use x macro for pass through compile human name lookup/getting. * WIP on parsing downstream compiler output. * Split out parsing into ParseDiagnosticUtil. Added test result of single line. * Dump out the std output on fail to parse diagnostics. * Change test type for syntax-error-intrinsic.slang be TEST not TEST_DIAGNOSTIC | 02 February 2021, 22:45:56 UTC |
5d755e5 | jsmall-nvidia | 29 January 2021, 22:12:38 UTC | Small improvements to CUDA doc (#1681) * #include an absolute path didn't work - because paths were taken to always be relative. * Small typo fixes for docs on CUDA target. | 29 January 2021, 22:12:38 UTC |
0ab4d04 | Tim Foley | 29 January 2021, 21:17:51 UTC | Fix issue when passing ray query to a subroutine (#1680) The problem would manifest for any code that declared a DXR 1.1 `RayQuery` value, but then only used it as one location in their code. The most common way for this to arise in user code was declaring a `RayQuery` and then handing it off to a helper/worker subroutine. RayQuery<0> myRayQuery; helperRoutine(myRayQuery, ...); The root cause was in the emit logic, where the initialization of `myRayQuery` above (a `defaultConstruct` operation in our IR) was getting folded into its (only) use site. This folding makes some sense, because the initialization of a ray query is not an operation with side effects, but doesn't work in practice because our way of handling default construction in HLSL output is by using a variable declaration. The simple fix here is to ensure that `defaultConstruct` instructions never get folded into use sites. If we decide to revisit the logic here, it might be possible to separate out the case where a `defaultConstruct` is being used as a stand-alone instruction, where we can emit it as: RayQuery<0> myRayQuery; versus cases where the `defaultConstruct` is being used as a sub-expression, such as: helperRoutine(RayQuery<0>(), ...); Whether or not we can emit the latter form (or if it would be equivalent) depends on details of how constructors like this are being implemented in dxc. For now it seems safest to emit things in a form that is obviously expected to work. Aside: Historically, the HLSL language has had no notion of "constructors" as being a thing. A variable that is declared but not initialized in HLSL has always been left uninitialized, since the first version of the language. The `RayQuery` type in DXR 1.1 is the first example of a type that appears to have a C++-style "default constructor," although HLSL as implemented by dxc still does not expose constructors as a user-visible or documented feature. (There is the small detail that the DXR 1.0 `HitGroup` type also relied on C++ constructor syntax, but I'm not aware of anybody using that feature right now, so it is mostly a curiosity.) | 29 January 2021, 21:17:51 UTC |
da6463a | jsmall-nvidia | 28 January 2021, 21:05:49 UTC | README.md update (#1679) * #include an absolute path didn't work - because paths were taken to always be relative. * Added trying out section to README.md Co-authored-by: Tim Foley <tfoleyNV@users.noreply.github.com> | 28 January 2021, 21:05:49 UTC |
615dfba | Yong He | 27 January 2021, 18:02:44 UTC | Make own a slang session. (#1678) | 27 January 2021, 18:02:44 UTC |
a90c850 | Tim Foley | 26 January 2021, 21:32:03 UTC | Integrate reflection more deeply into gfx layer (#1677) | 26 January 2021, 21:32:03 UTC |
50676c7 | jsmall-nvidia | 26 January 2021, 21:04:44 UTC | Obfuscation naming issue fix (#1676) * #include an absolute path didn't work - because paths were taken to always be relative. * Work around for issue with obfuscation (and lack of name hints) leading to names in output not being correctly uniquified. * Improve appendChar Remove unrequired memory juggling to scrub names. * Remove test code. * Small fixes in comments and method called. * Remove linkage decoration on functions that are specialized. * Obfuscation naming with specialization test. * Fix instruction deletion. Co-authored-by: Tim Foley <tfoleyNV@users.noreply.github.com> | 26 January 2021, 21:04:44 UTC |
798d773 | jsmall-nvidia | 26 January 2021, 17:15:08 UTC | Improved NVRTC location finding (#1674) * #include an absolute path didn't work - because paths were taken to always be relative. * WIP more sophisticated mechanism to find NVRTC. * Improve nvrtc searching to include PATH. * Make getting an extension able to differentiate between no extension, and just a . * Add comment. * Add support for searching instance path. * Small improvements around scope and finding NVRTC. * Improve documentation around NVRTC loading. | 26 January 2021, 17:15:08 UTC |
00fad59 | jsmall-nvidia | 22 January 2021, 21:18:04 UTC | Add nvrtc shared library/dll names (#1673) * #include an absolute path didn't work - because paths were taken to always be relative. * Add other NVRTC versions. Co-authored-by: Tim Foley <tfoleyNV@users.noreply.github.com> | 22 January 2021, 21:18:04 UTC |
6601220 | Yong He | 22 January 2021, 21:17:28 UTC | Further flatten IR natvis views (#1672) * Further flatten IR natvis views * improvements * formatting Co-authored-by: Yong He <yhe@nvidia.com> Co-authored-by: Tim Foley <tfoleyNV@users.noreply.github.com> | 22 January 2021, 21:17:28 UTC |
76db336 | Yong He | 22 January 2021, 17:22:45 UTC | Fix existential specialization of mutable buffer loads. (#1671) * Fix existential specialization of mutable buffer loads. * fix Co-authored-by: Yong He <yhe@nvidia.com> | 22 January 2021, 17:22:45 UTC |
dc063e5 | Yong He | 22 January 2021, 02:05:53 UTC | Make natvis to discover and display IRInst names more directly (#1670) Co-authored-by: Yong He <yhe@nvidia.com> | 22 January 2021, 02:05:53 UTC |
3fc90d4 | Yong He | 21 January 2021, 22:44:01 UTC | Initialize unused fields in packAnyValue (#1669) | 21 January 2021, 22:44:01 UTC |
b52fcf9 | Yong He | 21 January 2021, 22:21:55 UTC | Fix D3D12 DescriptorSet::setSampler bug (#1668) | 21 January 2021, 22:21:55 UTC |
b762c75 | Yong He | 21 January 2021, 21:55:38 UTC | Fix reflection to correctly report descriptor ranges of `StructureBuffer`s of existential types. (#1667) | 21 January 2021, 21:55:38 UTC |
6c8135f | Yong He | 21 January 2021, 20:21:00 UTC | Add `StructuredBuffer` support in `gfx`. (#1666) | 21 January 2021, 20:21:00 UTC |
4b97833 | Yong He | 21 January 2021, 18:25:00 UTC | Fix type legalization bug involving nested empty struct. (#1665) | 21 January 2021, 18:25:00 UTC |
3d21e7a | Tim Foley | 21 January 2021, 16:38:06 UTC | Upgrade slang-binaries for glslang 11.1.0 (#1664) This change also switches the build back to using prebuilt glslang binaries instead of always building from source. | 21 January 2021, 16:38:06 UTC |
660cf7a | Tim Foley | 20 January 2021, 17:23:39 UTC | Update glslang to 11.1.0 (#1662) * Update glslang to 11.1.0 This change pulls new versions of glslang, spirv-headers, and spirv-tools as submodules, and makes the necessary changes to other files in the repository to get it all building (at least on Windows). This change also enables building of glslang from source by default, so that we can easily generate new binaries for inclusion in the `slang-binaries` repository. * fixup: missing file | 20 January 2021, 17:23:39 UTC |
c6fd4a5 | Yong He | 19 January 2021, 17:10:15 UTC | Make `ShaderCursor` no longer depend on core. (#1661) | 19 January 2021, 17:10:15 UTC |
1296c7b | Yong He | 18 January 2021, 06:00:49 UTC | Make `gfx` compile to a DLL. (#1660) * Make `gfx` compile to a DLL. * Fix cuda * Fix cuda build * Bug gl screen capture bug. | 18 January 2021, 06:00:49 UTC |
2a5d5b3 | Tim Foley | 15 January 2021, 20:10:06 UTC | Convert more tests to use shader objects (#1659) This change converts a large number of our existing tests to use the `ShaderObject` support that was added to the `gfx` layer. In many cases, tests were just updated to pass `-shaderobj` and the result Just Worked. In other cases, a `name` attribute had to be added to one or more `TEST_INPUT` lines. For tests that did not work with shader objects "out of the box," I spent a little bit of time trying to get them work, but fell back to letting those tests run in the older mode. Future changes to the infrastructure will be needed to get those additional tests working in the new path. Along with the changes to test files, the following implementation changes were made to get additional tests working: * Because the shader object mode uses explicit register bindings (from reflection), the hacky logic that was offseting `u` registers for D3D12 based on the number of render targets gets disabled (by another hack). * The "flat" reflection information coming from Slang was not correctly reporting "binding ranges" for things that consumed only uniform data (which would be everything on CUDA/CPU), so it was refactored to properly include binding ranges for anything where the type of the field/variable implied a binding range should be created (even if the `LayoutResourceKind` was `::Uniform`). * A few fixes were made to the CUDA implementation of `Renderer`, in order to get additional tests up and running. Most of these changes had to do with texture bindings, which hadn't really been tested previously. In addition, a few changes were made that were attempts at getting more tests working, but didn't actually help. These could be dropped if requested: * As a quality-of-life feature (not being used) the `object` style of `TEST_INPUT` line is upgraded to support inferring the type to use from the type of the input being set. * Any `object` shader input lines get ignored in non-shader-object mode. | 15 January 2021, 20:10:06 UTC |
f834f25 | Yong He | 14 January 2021, 23:48:54 UTC | COM-ify all slang-gfx interfaces. (#1656) * COM-ify all slang-gfx interfaces. | 14 January 2021, 23:48:54 UTC |
ac76997 | jsmall-nvidia | 14 January 2021, 23:03:51 UTC | Adding missing VisualStudio lz4 project (#1657) * #include an absolute path didn't work - because paths were taken to always be relative. * Added missing lz4 visual studio project. | 14 January 2021, 23:03:51 UTC |
723796a | jsmall-nvidia | 11 January 2021, 20:24:11 UTC | LZ4 compression support (#1654) * #include an absolute path didn't work - because paths were taken to always be relative. * Testing out use of lz4. * Added ICompressionSystem, and LZ4 implementation. * Add support for deflate compression. Simplify compression interface - to make more easily work across apis. * WIP on CompressedFileSystem. * ImplicitDirectoryCollector * SubStringIndexMap - > StringSliceIndexMap. * WIP save stdlib in different containers. * Support for different archive types for stdlib. * Fix project. * CompressedFileSystem -> ArchiveFileSystem. Added CompressionSystemType::None * Added ArchiveFileSystem * Fix problem RiffFileSystem load withoug compression system. * Test archive types. Improve diagnostic message. * Fix typo in testing file system archives. * Split out archive detection. * Fix gcc warning issue. * Fix warning. * RiffArchiveFileSystem -> RiffFileSystem Co-authored-by: Tim Foley <tfoleyNV@users.noreply.github.com> | 11 January 2021, 20:24:11 UTC |
5554777 | Yong He | 11 January 2021, 17:11:52 UTC | Make `gfx::Renderer` a COM interface. (#1653) * Make `gfx::Renderer` a COM interface. This is a first step towards making the `gfx` library expose a COM compatible DLL interface. Remaining classes will come as separate PRs. * Fixup project files * Fix calling conventions * Make gfx::create*Renderer() functions increase ref count by 1 * Make renderer createFunc return via out parameter | 11 January 2021, 17:11:52 UTC |
e24c5a6 | Tim Foley | 08 January 2021, 00:01:48 UTC | Fill in some missing bits of capability API (#1652) * Fill in some missing bits of capability API * Make invalid/unknown capability have a zero value (this aligns it better with the public API for `SlangProfileID`, so that the two can be merged down the line) * Actually provide an implementation of `spFindCapability()` public API * fixup: bug fixes for renumbering invalid capability atom | 08 January 2021, 00:01:48 UTC |
d84f458 | Tim Foley | 07 January 2021, 21:16:18 UTC | Add a -capability command-line option (#1651) This provides a stand-alone option distinct from `-profile` that can be used to add capabilities to a target. A test has been added to confirm that `-profile X -capability Y` works the same as `-profile X+Y`. The intention is that this option could be used in applications that use the API to set up their target but then use the options-parsing logic to handle things like capabilities. Note: that latter bit has not been confirmed, so it is possible that this approach does not actually suffice for hybrid API + options usage. That will need to be confirmed in follow-up work. | 07 January 2021, 21:16:18 UTC |
66d4466 | Tim Foley | 07 January 2021, 20:18:55 UTC | Add support for [noinline] attribute (#1650) This adds the `[noinline]` attribute to the front-end, and passes it through when generating HLSL output. Notes: * This change doesn't include a test since the dxc version I have locally parses `[noinline]` but then generates DXIL that fails validation. * This change doesn't include logic to handle `[noinline]` for other targets. Notably, SPIR-V has decorations that convey the same intention, but we don't yet take advantage of the GLSL extension(s) that would let us generate those decorations. * By necesstiy, `[noinline]` is only a "strong suggestion" and not actually something the compiler can ever guarantee/enforce. | 07 January 2021, 20:18:55 UTC |
9263651 | Yong He | 06 January 2021, 20:58:57 UTC | Refactor GUI/Window utils out of gfx library (#1649) Co-authored-by: Yong He <yhe@nvidia.com> | 06 January 2021, 20:58:57 UTC |
706d4f9 | Tim Foley | 05 January 2021, 21:01:17 UTC | Add basic GLSL support for SV_Barycentrics (#1648) * Add basic GLSL support for SV_Barycentrics This change allows for fragment shader varying inputs marked with the `SV_Barycentrics` semantic to be mapped to GLSL code using the `gl_BaryCoordNV` builtin variable (from he `GL_NV_fragment_shader_barycentric` extension). This is the simplest possible change to get the functionality up and running, and it leaves out many things that could be desired in a more feature-complete version of the feature later: * There is no support for alternative extensions that provide similar functionality. Selection of which extension to favor could eventually be based on the "capability" work that has been put in place. * There is no attempt made to check that the input has the expected type (or to coerce it if it doesn't), so for now this is only going to be guaranteed to work for a `float3` input. * This change does not expose the `pervertexNV` qualifier added in the `GL_NV_fragment_shader_barycentric` extension, which can be used by a shader to access the uninterpolated vertex inputs. The last issue is an important one, since the HLSL `GetAttributeAtVertex` function seems to be defiend to work with *any* incoming varying parameter that was marked with `nointerpolation`. When we have a `nointerpolation` input, it would seem that we need to know whether it will be used with `GetAttributeAtVertex` (in which case it should be declared as a `pervertexNV` array input in GLSL) or not (in which case it should be declared as a `nointerpolation` input, without an array). * fixup: missing file | 05 January 2021, 21:01:17 UTC |
b4f9462 | Tim Foley | 05 January 2021, 17:00:00 UTC | Use "capability" system to select VKRT extension (#1647) * Use "capability" system to select VKRT extension Slang currently supports translation of ray tracing shader code to Vulkan GLSL code that uses the `GL_NV_ray_tracing` extension. A multi-vendor equivalent of that extension has been released as `GL_EXT_ray_tracing` and we want Slang to support that extension as well. At the simplest, making the change from one extension to the other is just a matter of changing a few strings, since it does not appear that anything of significance was changed at the GLSL level (or even in SPIR-V). Where this gets trickier is when we have users who want us to support *both* extensions, and to be able to switch between them. The solution we've implemented here more or less amounts to: * If you don't tell the compiler which extension to use, it will default to `GL_EXT_ray_tracing` (the newer multi-vendor one). * If you explicitly want the older extension, you can opt into it using the `-profile` option or via a new API for explicitly adding capabilities to your target. Making that work required a few different kinds of changes: * The options parsing and public API needed ways to add optional capabilities to a target. * During GLSL code emit, we can check the capabilities that were added to the target to see if the `GL_NV_ray_tracing` extension was explicitly enabled and, if not, default to using the `GL_EXT_ray_tracing` names for things. This step is needed because some of the modifiers/attributes involved in the extension have to be handled explicitly in the code generator rather than implicitly as part of mapping intrinsic functions. * We add two different translations to the relevant operatiosn in the stdlib, one marked with each of the extensions. If profile/capability-based overload resolution can be relied on to pick the right one, this should Just Work. * Next, a bunch of work had to go into making capability-based overloading Just Work for the purposes of this change. There's been a nearly complete reworking of the implementation of `CapabilitySet` here to make it more suitable for our needs. * The tests that were using ray tracing translation for Vulkan needed to be updated. For some of them I updated their baselines to use `GL_EXT_ray_tracing` so that they can test the new path. For others, I updated the command line for the test case so that it explicitly opts into using `GL_NV_ray_tracing`. The result is that we have some coverage of each extension. I would have liked to have each test run in both modes, but our pass-through glslang support doesn't support `-D` options, so I couldn't take that step easily. This change does *not* add support for `GL_EXT_ray_query`, the extension that supports "DXR 1.1" style queries under Vulkan. Adding support for that extension should hopefully be a smaller step because it doesn't have the same multiple-extensions issue. This change does *not* address a lot of possible avenues for improvement or cleanup around the capability system. It focuses only on those changes that are necessary to make the ray tracing feature work and leaves the rest for future work. * fixup: infinite loop * Comment-only change to retrigger TC build | 05 January 2021, 17:00:00 UTC |
f5fffa9 | Dietrich Geisler | 18 December 2020, 17:10:10 UTC | Heterogeneous Flag Error Visibility (#1642) * PR to fix issue #1638. This change introduces a diagnostic sink to the emitModule function, and updates all associated calls to that function. Additionally, this commit updates the heterogeneous hello world example to not need the entry and stage flags for simplicity. * Updated emit-cpp per suggested changes Co-authored-by: Tim Foley <tfoleyNV@users.noreply.github.com> | 18 December 2020, 17:10:10 UTC |
0fa3bcf | Yong He | 15 December 2020, 20:57:55 UTC | Cleanup CUDA renderer. (#1644) * Cleanup CUDA renderer. * More cleanup * fixes. * update comments Co-authored-by: Yong He <yhe@nvidia.com> | 15 December 2020, 20:57:55 UTC |
77bc70e | jsmall-nvidia | 15 December 2020, 19:04:10 UTC | OSX Build/glslang premake fix (#1641) * #include an absolute path didn't work - because paths were taken to always be relative. * Improve docs. Fix premake build of glslang. * More improvements to the building.md doc. | 15 December 2020, 19:04:10 UTC |
1bc7948 | jsmall-nvidia | 14 December 2020, 21:18:51 UTC | Enable embedding stdlib for github builds (#1640) * #include an absolute path didn't work - because paths were taken to always be relative. * Enable building with embedding stdlib. | 14 December 2020, 21:18:51 UTC |
856d7d3 | Yong He | 11 December 2020, 17:42:23 UTC | Implements CUDA renderer in gfx. (#1637) * Implements CUDA renderer in gfx. * Revert unnecessary change. * Revert unnecessary changes. Co-authored-by: Tim Foley <tfoleyNV@users.noreply.github.com> | 11 December 2020, 17:42:23 UTC |
992778e | Tim Foley | 11 December 2020, 16:50:43 UTC | Add first steps toward a "capability" system (#1636) * Add first steps toward a "capability" system We already have cases in the stdlib where we mark declarations as being specific to certain targets, e.g.: ``` // My ordinary function to add two numbers. // Works everywhere. // void myFunc(int a, int b) { return a + b; } // On the "coolgpu" target, we can use a secret intrinsic // that adds numbers even faster! // __specialized_for_target(coolgpu) void myFunc(int a, int b) { return __secretIntrinsic(a, b); } ``` The existing logic for dealing with these modifiers (`__specialized_for_target` and `__target_intrinsic`) was almost entirely string-based. We would turn the chosen compilation target into a string, and then use that to try and search for the "best" definition of a function at a few steps: * During IR linking, we always pick one definition of an `[import]`ed function, and that definition will be the one with the "best" target-specialization modifier (if any) * During final code generation, we always look up the "best" target-intrinsic modifier, and use it as the template for the code we output. This change preserves the basic flow there, but replaces the ad hoc string-based logic with something a bit more principled, in terms of a new `CapabilitySet` type. A `CapabilitySet` represents a set of zero or more atomic features (here represented as `CapabilityAtom`s). What a `CapabilitySet` means depends on how and where it is used: * A compilation target implies a `CapabilitySet` where the contents of the set are the features the target *supports*. * A `CapabilitySet` attached to a declaration (or a modifier on that declaration) describes a set of feature that declaration *requires*. The current implementation of `CapabilitySet` is wasteful and inefficient, but that is something we can iterate on over time. In practice, most of the current code only ever uses capability sets that are either empty (because they represent a function with no specific requirements) or singleton (because they represent asingle atomic capability like "is a GLSL target," "is an HLSL target," etc.). The main goal here was to put in the skeleton of a new system, including some of the features it might need down the line, and then to leave changes that eventually use the greater flexibility for later. Eventually, the capability system should encompass: * Differences between shader model versions, GLSL versions, SPIR-V versions, etc. (currently tracked with other modifiers) * Optional extensions, and functions that are made available only with certain extensions (currently tracked with other modifiers) * Front-end checking that the call graph of a program doesn't violate any capability-requirements (e.g., having a GLSL+HLSL portable function call a GLSL-only subroutine) * Hypothetically we can also try to fold stage-specific (vertex-only, fragment-only, etc.) functions into this system, but doing so would require more linker cleverness if we allow overloading on stages (since we might have to clone a caller if it calls through to a callee with multiple stage-specific versions) One important complication that the system has to deal with just because of the "do what I mean" nature of the current compiler is that somethings a current Slang user might compile for target X and specify version N, but then use a function that actually requires version N+1 of that target. Currently the Slang compiler silently "upgrades" the version(s) used by user code in these cases, because it is often what users want in cross-compilation scenarios. Dealing with the "silent upgrade" situation requires us to be a little careful and sometimes pick a "best" capability set that doesn't appear to be supported on our target. Refining that system and potentially getting rid of the "do what I mean" behavior over time could be a goal for future changes. * fixup: handle case where value is incompatible during linking | 11 December 2020, 16:50:43 UTC |
4337338 | jsmall-nvidia | 10 December 2020, 19:04:29 UTC | Building with embedded stdlib (#1634) * #include an absolute path didn't work - because paths were taken to always be relative. * Move reflection to reflection-api. * Slight reorg to pull out potentially Slang internal functions from the reflection API impls. * Remove visual studio projects * Fix for slang-binaries copy. * Add the visual studio projects in build/visual-studio * Remove miniz project. * Differentiate the linePath from the filePath. * Improve comment in premake5.lua + to kick of CI. * Kick CI. * Use COM compile request for calls to functions inside api-less-slang. Add static-slang project. * Fix const typo issue. * Don't include 'core' link in 'api-less-slang' * Removed static-slang lib causes problems on linux with linking. Embed Slang stdlib Added StaticBlob Added dumpSourceBytes Use ConstArrayView for the archive. At startup allow loading of zip with stdlib. Made -save-stdlib -load-stdlib take a name Added '-save-stdlib-bin-source' to save out serialized stdlib as source. * Ability enable/disable stdlib embedding. * Fix problem with moduleDecl not having module pointer set when serialized in. * Set of debugdir for slang-test and examples. * Add slang-stdlib-api.cpp * Update slang filters for VS. * Try to use pic, and -mcmodel=medium * Some more efforts ot make premake work. * WIP premake5.lua from previously working version. * Remove api-less-slang project. * Disable dllexport on gcc/clang. * Embed via slangc-bootstrap. * Fix slang-profile. Always compiles without stdlib. * Use pic "On" * Remove slangc-bootstrap and embed-stdlib-generator if embedding not required. Make bootstrap run the generators. * Improve comments in premake5.lua. Kick off another CI build. * Remove generation of stdlib source from std-lib-serialize.slang | 10 December 2020, 19:04:29 UTC |
e4a8251 | Yong He | 10 December 2020, 17:43:09 UTC | Move ShaderObject to be under renderer interface. (#1633) * Move ShaderObject to be under renderer interface. * Make `create*PipelineState` take `const PipelineStateDesc&`. * Move ShaderCursor implementation to a cpp file | 10 December 2020, 17:43:09 UTC |
b8e1f62 | Tim Foley | 08 December 2020, 02:18:31 UTC | Fix a subtle bug introduced into type legalization (#1632) The refactor of type legalization in PR #1594 introduced a subtle problem where an IR instruction might be removed from the hierachy (perhaps because its parent was removed during legalization) but would still be on the work list. Legalization of such instructions is wasteful (since it would never impact the output), but it also creates a problem if we try to insert new legalized instructions next to such a removed instruction. The logic for inserting an instruction before/after another asserts that the sibling instruction must have a parent, and leads to a failure in debug builds and a potential crash in release builds. This change adds a bit of defensive code to skip any instructions that appear to have been removed from the hierarchy (because they have no parent and are not the root/module instruction). An alternative approach would be to try to detect these instructions at the point where they would be added to the work list, but this approach seems simpler and more general. | 08 December 2020, 02:18:31 UTC |
0404fef | Tim Foley | 07 December 2020, 22:17:17 UTC | Fix mistake where some public API functions weren't extern "C" (#1631) This was a serious problem that meant that some of our public API functions (exported from the DLL) had mangled C++ symbol names (which are not guaranteed to be portable across different compilers). The fix here is the expedient one: just add `extern "C"` to the relevant functions. The simplicity has a cost, though, in that this change introduces a significant break in binary compatibility. Source code should be compatible before/after this change, but it would be necessary to match an application and Slang shared library so that they agree on the mangled names of these symbols. We will need to treat this as a breaking release when this change goes out. Note that because of the way that C++ mangled names were being used, we *already* have introduced breaking changes to the binary interface in a recent change that made `SlangCompileRequest` into a `typedef` instead of a forward-declared `struct` type. To be clear, the breakage was due to the missing `extern "C"` and *not* the content of that change; the change would have been binary-compatible if the symbol names were correct. Given that the cat is out of the bag to some extent (our next release is going to break compatibility one way or another), it seems best to just get the whole thing sorted at once. | 07 December 2020, 22:17:17 UTC |
d7ce74a | Tim Foley | 07 December 2020, 17:29:37 UTC | "Shader Toy" example and related fixes (#1629) * "Shader Toy" example and related fixes This change introduces a new `shader-toy` example program that is primarily designed to show how Slang's features for type-based encapsulation and modularity can be applied to modularity for effects along the lines of those from `shadertoy.com`. The Example ----------- The example is being checked in with an example "toy" effect that I hastily put together, so that it would not be encumbered with any IP concerns. I wrote the effect using the shadertoy.com editor, so I can be sure it is valid GLSL. During bringup of the application I used a pre-existing and larger effect for testing, so some of the support code that was added is not being used at present. The big-picture idea here is to have an exmaple that shows how to modularize things using Slang interfaces and generics, and then to use the Slang compiler API to manage the compilation, composition, specialization, and linking steps. For better or worse this leads to the sequence of API calls involved being much longer than what was in something like the `hello-world` example. Future Work (Example) --------------------- There is a lot of room for improvement and expansion here, so this should be viewed as a checkpoint of work in progress rather than something I'm claiming as a finalized demonstration of all we'd like to achieve. Areas for future work include: * We need to copy the integration of "Dear, IMGUI" that was already done for the `model-viewer` example so that this example can have a UI. * Now that the compilation flow is broken into all these additional steps, it should be possible to have the application load multiple effects as distinct modules, and then provide a UI for switching between them. The chosen effect module would be used to specialize the top-level shader(s) before kernel generation. * The checked-in logic includes a compute shader that can execute an effect, but that hasn't been tested nor has it been wired up to any kind of UI. We should have a way to switch between multiple execution methods, with a goal of eventually including CPU execution. * The "GLSL compatibility" code needs a lot of improvements before it is likely to be usable for a nontrivial number of shaders. Some of that work is waiting on Slang compiler fixes, though. * We should consider allowing the individual "toy" effects to define their own uniform parameters and expose those via a UI and reflection. The catch in this case is not that this would be difficult to do, but that it would be a semantic change to how shader toy effects currently work. The Compiler Fixes ------------------ Doing this work exposed a few bugs in Slang, and this change includes fixes for the ones that were quick to address. We already had logic in `slang-check-shader.cpp` that was validating the entry points in a compile request - either by checking the explicitly-listed entry points, or by scanning for `[shader("...")]` attributes. The problem is that the routine that did that checking was not being invoked on all compiles. The logic that handled entry points was only being run for manual compiles using `SlangCompileRequest`, while anything using `import` or `loadModule` would ignore entry points. I refactored the relevant code into a subroutine that will be invoked in all compilation scenarios. There were already `TODO` comments in `SpecializedComponentType` which made the point about how a specialized entry point like `myShader<YourType>` would need to properly show that it has dependencies on both the module that defines `myShader` *and* the module that defines `YourType`, while only the former was being handled at present. I went ahead and implemented the logic to scan the generic arguments for a specialized compoment type in order to determine what module(s) the arguments depend on (both type arguments and witness tables). With that change, using `IComponentType::link` on a specialized component will properly pull in the module(s) that the generic arguments come from. In `slang-ir-legalize-types.cpp` we could run into assertion failures in debug builds because of code trying to legalize layout `IRAttr`s for fields or parameters with types that need legalization. In practice it is safe to skip these layout attributes, because legalization of the fields/parameters they pertain to would result in creation of entirely new layout attributes, and the old ones would then be unreferenced. Future Work (Fixes) ------------------- There are other compiler bugs that this work exposed, but which this change does not address. These will need to be resolved as part of subsequent changes: * Slang allows for default-initialization of variables of a generic type. That is, given `<T : ISomething>` a user is allowed to declare `T x = {};` and the Slang front-end does not complain. Instead, this leads to an internal compiler error during IR lowering. * The Slang `__init()` feature probably needs to be upgraded to a properly supported feature, and we probably need a way to make implementing default-initialization an easy thing (e.g., any `struct` type that has initial-value expressions for all its fields should automatically and implicitly satsify an `init();` requirement declared in an interface) * Iniside an `__init()` definition, code has mutable access to members of the enclosing type, but for some reason the front-end is incorrectly treating `this` as immutable in those contexts. As a result you can write to `someField` but not `this.someField`. * User-defined operator overloads flat out don't work (which isn't surprising given that no clients have decided to use them yet, and we have no test coverage for them). This is actually due to the shadowing rules being used for lookup right now, so a fix for this issue is going to have far-reaching consequences around what overloads are visible where (and anything that impacts overload resolution is a big can of worms, including around performance). * fixup: test case had missing main function | 07 December 2020, 17:29:37 UTC |
e98c32f | Yong He | 04 December 2020, 18:44:03 UTC | add windows release script (#1627) Co-authored-by: Tim Foley <tfoleyNV@users.noreply.github.com> | 04 December 2020, 18:44:03 UTC |
47ed0f6 | jsmall-nvidia | 04 December 2020, 18:03:29 UTC | Projects in 'build' and Slang API separation (#1624) * #include an absolute path didn't work - because paths were taken to always be relative. * Move reflection to reflection-api. * Slight reorg to pull out potentially Slang internal functions from the reflection API impls. * Remove visual studio projects * Fix for slang-binaries copy. * Add the visual studio projects in build/visual-studio * Remove miniz project. * Differentiate the linePath from the filePath. * Improve comment in premake5.lua + to kick of CI. * Kick CI. | 04 December 2020, 18:03:29 UTC |
277780a | Yong He | 03 December 2020, 22:48:42 UTC | Add github action to verify vs project file consistency. (#1625) * Add github action to verify vs project file consistency. * fix solution files * fix project files | 03 December 2020, 22:48:42 UTC |
a827798 | jsmall-nvidia | 03 December 2020, 17:55:29 UTC | Added miniz Visual Studio Project (#1623) | 03 December 2020, 17:55:29 UTC |
44c0a56 | Yong He | 03 December 2020, 16:23:05 UTC | Add shader object parameter binding to renderer_test. (#1622) * Add shader object parameter binding to renderer_test. * remove multiple-definitions.hlsl * Fix cuda implementation. Co-authored-by: Tim Foley <tfoleyNV@users.noreply.github.com> | 03 December 2020, 16:23:05 UTC |
ad5dda9 | Tim Foley | 02 December 2020, 22:12:51 UTC | Fix [mutating] generic methods (#1618) Slang generates code that turns the implicit `this` parameter of a method into an explicit parameter. The logic that decides whether that parameter should be `inout` is a bit involved, and there was a bug where a generic method would lead to the use of an `in` modifier (the default) and override the `inout` modifier that was requested by the method itself. This change fixes the logic to treat generic declarations in the parent chain of a leaf method as having no bearing on whether an implicit `this` parameter should be `inout` or not. A test case is included that breaks with the old behavior, and demonstrates that a generic `[mutating]` method can now work correctly. | 02 December 2020, 22:12:51 UTC |
ae222bf | jsmall-nvidia | 02 December 2020, 16:29:38 UTC | Zip FileSystem support (#1617) * #include an absolute path didn't work - because paths were taken to always be relative. * Add miniz * Fix for separator in CacheFileSystem. Add compression unit test for zip. * Put zip compression into core. * Remove delimiter stripping if simplifying a path - as stripping will fix delimiters. * ZipFileSystem WIP. * More ZipFileSystem working. * Added isEmpty. Fixed small bug is contains. * First pass support for mutability on zip. * Improvements to File::read/writeAllBytes * Can access and save archive - but has memory leaks. * Fix memory leak. * Some ZIP compression tests. * Fix memory leak on ScopedAllocation. Fix off by one bug on UIntSet * Bug fix in UIntSet * Fix remaining ZipFileSystem issues. Adde stand alone unit-test. * Turn tabs to spaces in slang-io.h * Renamed mode ReadWrite (instead of just Write) * Make miniz it's own project. * Fix windows warning on win32. * Remove warnings needed when miniz was included as a header library. * Set the C++ standard via 'flags' in premake. * Add support for 'implicit' paths. * Add testing for implicit directories. Better handling of implicit directories. * Improve comments in ZipFileSystem. * Update comment around reader/writer transformation. | 02 December 2020, 16:29:38 UTC |
e631a25 | jsmall-nvidia | 02 December 2020, 13:45:08 UTC | Fix for TC problem with Path unit test (#1621) * #include an absolute path didn't work - because paths were taken to always be relative. * Hopefully fix for TC issue where canonical path causes problems - perhaps because on test machines visibility of paths outside the build environment is limited. | 02 December 2020, 13:45:08 UTC |
200e236 | jsmall-nvidia | 01 December 2020, 22:29:01 UTC | Make SlangCompileRequest COM type (#1620) * #include an absolute path didn't work - because paths were taken to always be relative. * WIP for COM CompileRequest. * Add more methods to IGlobalSession. * Fix createCompileRequest. Made slangc tool use COM style methods. * m_ prefix variables in EndToEndCompileRequest | 01 December 2020, 22:29:01 UTC |
339422d | Yong He | 30 November 2020, 16:59:34 UTC | Enable all dynamic-dispatch tests on D3D/VK. (#1615) | 30 November 2020, 16:59:34 UTC |
de8dbdd | Yong He | 30 November 2020, 16:59:02 UTC | Re-enable `interface-shader-param` tests. (#1614) | 30 November 2020, 16:59:02 UTC |
c0fab43 | jsmall-nvidia | 20 November 2020, 22:24:35 UTC | Bug fixes: Memory leak/off by one on UIntSet (#1616) * #include an absolute path didn't work - because paths were taken to always be relative. * Fix memory leak on ScopedAllocation. Fix off by one bug on UIntSet | 20 November 2020, 22:24:35 UTC |
ee5842a | Yong He | 20 November 2020, 16:34:14 UTC | Make witness and RTTI handles lower to `uint2`. (#1613) * Make witness and RTTI handles lower to `uint2`. And enable some dynamic dispatch tests on D3D/VK. * Bug fixes. | 20 November 2020, 16:34:14 UTC |
4459d44 | Tim Foley | 19 November 2020, 09:26:43 UTC | Unify handling of static and dynamic dispatch for interfaces (#1612) Overview ======== Prior to this change, we had two different code generation strategies for interface/existential types in Slang, that didn't always play nicely together: * The "legacy" static specialization approach could handle plugging in an arbitrary concrete type for an existential type parameter (including types with resources, etc.), but wouldn't work well with things like a `StructuredBuffer<>` of an interface type, and requires somewhat counter-intuitive layout rules to make work. * The new dynamic dispatch approach produces simpler, more easily understood layouts by assuming that values of interface type can fit into a fixed number of bytes. The tradeoff there is that it cannot handle types that include resources (only POD types). The goal of this change is to make it so that the two strategies can co-exist. In particular, in cases where a shader is amenable to both static specialization and dynamic dispatch, the type layouts should agree. In order to make the type layouts agree, we: * Declare that *all* values of existential type reserve storage according to the dynamic-dispatch rules (so 16 bytes for the RTTI and witness-table information, plus whatever bytes are needed to story "any value" of a conforming type). * Then we modify the "legacy" layout rules so that if a value of concrete type can fit in the reserved "any value" space for a given interface, then it is laid out there exactly like the dynamic dispatch rules would do. Otherwise, we fall back to the previous legacy rules (since we don't need to agree with the dynamic-dispatch layout on types that can't be used with dynamic dispatch). Details ======= * Renamed `ExistentialBox` to `BoundInterfaceType` to better clarify how it relates to `BindExistentialsType` * Unconditionally apply the `lowerGenerics` pass during emit, since it is now responsible for aspects of the lowering of existential types when specialization is used. * Made IR type layout take the target into account, so that the layout of resource types can vary by target (e.g., being POD on some targets, and invalid on others) * Cleaned up some issues around using global shader parameters as the "key" for their layout information in the global-scope layout (only comes up when there are global-scope `uniform` parameters) * Made there be a default any-value size (16) instead of making it be an error to leave out. This was the simplest option; we could try to go back to having an error, but we'd need to only issue it if we are sure a type/interface is being used with dynamic dispatch, since static dispatch doesn't have to obey the restrictions. * Changed lowering of existential types to tuples so that bound interfaces where the concrete type won't fit use a "pseudo-pointer" instead of an "any-value" to hold the payload * Changed IR type legalization to handle the "pseudo-pointer" case and apply layout information from an interface type over to the payload part when static specialization was used. * Changed some details of how witness tables were being lowered, so that we didn't have to create "proxy" witness tables for the constraints on associated types (just use the actual requirement entries we generate) * Changed witness tables so that they know the subtype doing the conforming * Added logic so that we don't generate pack/unpack logic and witness table wrapper functions for types that are incompatible with any-value/dynamic dispatch for a given interface. * Changed the core AST-level type layout logic to use the dynamic-dispatch layout in case things fit, and the legacy static specialization case when things don't (while also reserving space for the dynamic-dispatch fields) * Changed a bunch of test cases for static specialization to properly use the new layout (which introduces new buffers in some cases, and moves data around in others). Future Work =========== The experience of trying to reconcile our older way of handling interface-type specialization with our newer model (that supports dynamic dispatch) makes it clear that we really need to make similar changes to our handling of generic type parameters on entry points and at the global scope. A future change should make it so that a global type parameter is lowered with a type layout similar to a value parameter of interface type, including the RTTI and witness-table pieces, and just leaving out the "any value" piece. A similar translation strategy should apply to entry-point generic parameters (mirroring how we lower generic functions for dynamic dispatch already), and value specialization parameters. Co-authored-by: Yong He <yonghe@outlook.com> | 19 November 2020, 09:26:43 UTC |
b594510 | jsmall-nvidia | 19 November 2020, 09:14:48 UTC | File system refactor (#1611) * #include an absolute path didn't work - because paths were taken to always be relative. * WIP FileSystem refactor. * Made loadFile load the file in binary mode. * Fixed some comments. Fixed typo in RelativePath - not used 'fixedPath'. | 19 November 2020, 09:14:48 UTC |
ac41b99 | Yong He | 19 November 2020, 09:14:34 UTC | Fix constant folding in attributes (#1610) * Fix constant folding in attributes * remove unnecessary change * remove unnecessary change * remove unnecessary change * Fixed circular checking issue. * cleanup * more cleanup * minimize diff * minimize diff * minimize diff | 19 November 2020, 09:14:34 UTC |
e140c49 | jsmall-nvidia | 18 November 2020, 23:12:43 UTC | Test for serializing out and reading back Stdlib (#1605) * #include an absolute path didn't work - because paths were taken to always be relative. * Mangling/module name extraction for GenericDecl * Add comment on SerialFilter to explain re-enabling Stmt. * Support setting up SyntaxDecl when reconstructed after deserialization. * Improvements to setup SyntaxDecl. * Fix typo so can read compressed SourceLocs. * Fix issue with SourceManger. * Simple test for serializing out stdlib and reading back in. * Fix calling convention. * Add override to StdLib impls. * Fix typo. * Apply testing to an actual compute test when using load-stdlib Make -load/compile-stdlib processable by Slang Move out testing into util into TestToolUtil so can be shared. * Slightly more concise setup of session. * Fix some errors introduced with session handling. * Made setup for compile same across slangc and slangc-tool. | 18 November 2020, 23:12:43 UTC |
d898d56 | jsmall-nvidia | 18 November 2020, 19:52:58 UTC | Serialized stdlib working (#1603) * #include an absolute path didn't work - because paths were taken to always be relative. * Mangling/module name extraction for GenericDecl * Add comment on SerialFilter to explain re-enabling Stmt. * Support setting up SyntaxDecl when reconstructed after deserialization. * Improvements to setup SyntaxDecl. * Fix typo so can read compressed SourceLocs. * Fix issue with SourceManger. | 18 November 2020, 19:52:58 UTC |
bdc589b | Yong He | 17 November 2020, 20:03:45 UTC | Switch CI to github actions. (#1609) * Remove travis config files * change github build script * skip non-tag build on appveyor | 17 November 2020, 20:03:45 UTC |
7dd0ff9 | Yong He | 17 November 2020, 16:57:13 UTC | Integrate github actions for linux deployment. (#1607) | 17 November 2020, 16:57:13 UTC |
39709fb | Yong He | 17 November 2020, 16:56:33 UTC | Integrate github actions for build+test on Windows. (#1606) | 17 November 2020, 16:56:33 UTC |
f4dbe7d | jsmall-nvidia | 17 November 2020, 14:49:03 UTC | Fix premake5.lua for profile (#1604) * #include an absolute path didn't work - because paths were taken to always be relative. * The Profile project wasn't including the generated prelude. | 17 November 2020, 14:49:03 UTC |
46e1901 | Yong He | 16 November 2020, 19:18:55 UTC | Fix VS2017 Warnings (#1602) * Fix VS2017 Warnings * Update slang-visitor.h Co-authored-by: jsmall-nvidia <jsmall@nvidia.com> | 16 November 2020, 19:18:55 UTC |
2c893d3 | Yong He | 11 November 2020, 20:33:32 UTC | Integrate github action for linux build+test. (#1601) | 11 November 2020, 20:33:32 UTC |
8f0895e | jsmall-nvidia | 11 November 2020, 14:56:50 UTC | Include hierarchy output (#1595) * #include an absolute path didn't work - because paths were taken to always be relative. * Improve diagnostic for token pasting. * Token paste location test. * Output include hierarchy. * WIP on includes hierarchy. * Improved include hierarchy output - to handle source files without tokens. Improved test case. * Small comment improvements. Fixed a typo with not returning a reference. * Slight simplification of the ViewInitiatingHierarchy, by adding GetOrAddValue to Dictionary. * Remove the need for ViewInitiatingHierarchy type. * Improve output of path in diagnostic for includes hierarchy. * Remove comment in diagnostic for token-paste-location.slang * Update command line docs to include `-output-includes` Co-authored-by: Yong He <yonghe@outlook.com> | 11 November 2020, 14:56:50 UTC |
7bcc2b1 | Yong He | 10 November 2020, 22:55:36 UTC | Use integer RTTI/witness handles in existential tuples. (#1598) * Use integer RTTI/witness handles in existential tuples. * Fix clang error. * Fix IR serialization to use 16bits for opcode. * Undo accidental comment change. * Use variable length encoding for opcode. * Fix compile error. * Fixing issues * Fix code review issues. | 10 November 2020, 22:55:36 UTC |
1c4d768 | Yong He | 10 November 2020, 21:07:42 UTC | Fix IR serialization to use variable length encoding for opcode. (#1599) * Fix IR serialization to use 16bits for opcode. * Undo accidental comment change. * Use variable length encoding for opcode. * Fixing issues | 10 November 2020, 21:07:42 UTC |
c1e0a9d | Yong He | 06 November 2020, 18:31:15 UTC | Fix comments. "white-list" -> "allow-list". (#1597) | 06 November 2020, 18:31:15 UTC |
444ff4d | Yong He | 06 November 2020, 18:26:27 UTC | Specialize witness table lookups. (#1596) * Specialize witness table lookups. * Remove generated files from vcxproj * Fix call to generic interface methods. | 06 November 2020, 18:26:27 UTC |
94861d5 | Tim Foley | 06 November 2020, 17:12:14 UTC | Set theme jekyll-theme-tactile | 06 November 2020, 17:12:14 UTC |
0f6765b | Tim Foley | 06 November 2020, 00:11:56 UTC | Refactor the flow of type legalization (#1594) The existing type legalization logic worked as a single preorder pass over the IR tree. This could create problems in cases where an instruction might be processed before one of its operands (e.g., a function that references a global shader parameter is processed before that parameter). This change makes it so that type legalization uses a work list, and only adds instructions to the work list once their parent, type, and operands have been processed. As a result, we should be able to guarantee that an instruction will only be processed once all of its operands have been. One wrinkle here is that in the current IR it is possible to end up with a cycle of uses for global-scope instructions, specifically around interface types and their list of requirements. This change includes a short-term kludge to break those cycles and allow the pass to complete. As it stands, this is simply a refactoring pass and no new functionality is introduced. The changes are necessary to unblock work in a feature branch that depends on type legalization being more robust against IR that might use an unexpected ordering. | 06 November 2020, 00:11:56 UTC |
c985f5f | jsmall-nvidia | 05 November 2020, 18:43:00 UTC | Standard library save/loadable (#1592) * #include an absolute path didn't work - because paths were taken to always be relative. * Fix handling of access modifiers inside type definition. * Fix access problem for AST node. Make dumping produce a single function with switch, to potentially make available without Dump specific access. * WIP on serialization design doc. * Remove project references to previously generated files. * More docs on serialization design. * Improve serialization documentation. Remove unused function from IRSerialReader. * Small fixes around naming. Remove long comment from slang-serialize.h - as covered in serialization.md * Remove long comment in slang-serialize.h as covered in serialization.md * More information about doing replacements on read for AST and problems surrounding. * Typo fix. * Spelling fixes. * Value serialize. * Value types with inheritence. * Use value reflection serial conversion for more AST types * Use automatic serialization on more of AST. * Get the types via decltype, simplifies what the extractor has to do. * Update the serialization.md for the value serialization. * Small doc improvements. * Update project. * Remove ImportExternalDecl type Added addImportSymbol and ImportSymbol type Fixed bug in container which meant it wouldn't read back AST module * Because of change of how imports and handled, store objects as SerialPointers. * First pass symbol lookup from mangled names. * Cache current module looked up from mangled name. * Fix SourceLoc bug. Improve comments. * Added diagnostic on mangled symbol not being found * Fix typo. * WIP serializing stdlib. * WIP serializing stdlib in. * Fix problem serializing arrays that hold data that is already serialized. * Remove clash of names in MagicTypeModifier. * Make conversion from char to String explicit. Fix reference count issue with SerialReader. * Add code to save/load stdlib. * Use return code to avoid warning - SerialContainerUtil::write(module, options, &stream)) * Make all String numeric ctors explicit. Added isChar to UnownedStringSlice. Added operator== for UnownedStringSlice to String to avoid need to convert to String and allocate. * Add error check to readAllText. * tabs -> spaces on String.h * tab -> spaces String.cpp * Remove msg for StringBuilder, just build inplace for exceptions. * Check SerialClasses - for name clashes. Renamed Modifier::name as Modifier::keywordName * Handling of extensions when deserializing AST - updating the moduleDecl->mapTypeToCandidateExtensions Co-authored-by: Tim Foley <tim.foley.is@gmail.com> | 05 November 2020, 18:43:00 UTC |